This project explores the ideas introduced by the Self programming language and aims to bring them to the current age. The ultimate goal is to create a semi-visual tool for building web apps in a more intuitive way using just one programming language - TypeScript - on the client & on the server, and without the accidental complexity.
The project is in early alpha stage with the bus factor of (strong) 1. :)
Happy to answer any questions here or at firstname.lastname@example.org*
PS. I’m creating a todo app using Kretes on YouTube  to explain the bigger picture of building full-stack applications. IMHO it’s good to have a general understanding of how web applications work before* specializing in front-end or back-end - that’s the goal for this video series, and for Kretes.
 not yet public
For those of us unaware of what the Self programming language is/was, what things did you find inspiring that you are using in this framework?
I must mention DarkLang  that seems to have a similar goal, but a different approach: Kretes builds on top of VS Code, and uses one of the most popular programming languages while DarkLang builds not only their editor from scratch, but they also introduced a new programming language. I find their project ambitious and inspiring - a potential game changer imho
Does it include an autogenerated admin page like Django?
Does it handle database migrations?
You mention both Vue and React in your page, does that mean I have to install either of them manually or does the cli handle that?
What are the limitations of the query builder?
I can't test anything right now and the docs page looks a bit bad on my phone. Also the examples page is broken and returns an error.
1. I'm working on the admin panel, but it's not yet ready. I'm still hesitating how to approach the persistence layer without introducing too many abstractions. Generally speaking, I'd like to avoid ORMs as much as possible. :)
2. I use the node-pg-migrate  for migrations at the moment, but I plan to tightly integrate with Postgraphile / Hasura to give another approach for that part.
3. You need to add them manually, but the architecture is pretty close to Vite . You have just one Node process for both front-end & back-end: in development I compile assets on the fly using ESBuild , in production I bundle them using Rollup. I should probably describe that in the docs more clearly :) In contrast to Vite, Kretes also provide a REST API out-of-the-box, and a relatively simple path for adding a GraphQL endpoint.
4. The current query builder - sqorn  - has a nice syntax as it uses the same vocabulary as SQL, but it's not typed. My goal is to create a fully typed TypeScript query builder that's adapted only for PostgreSQL. Here's the preliminary work for that 
5. I'm still working on the docs. I'll fix the things you mentioned right away.
Disclaimer: As the project is in early alpha, this promise is not yet fully fulfilled. :)
I'm always wondering people are not interested in powerful interactive development environments anymore. Like those environments for Smalltalk and Common Lisp. Modern development sucks.
I hope there would be more things like this.
The project, however, is in early alpha, still far from being close to a programming environment per se.
I see that Kretes uses Sqorn  for talking to the database.
I really like the looks of Sqorn, however iiuc, it doesn't support typescript right?
How does that piece work?
That looks like a really good start. Do you think it'll end up looking like JOOQ? Would be interesting to see how you get things like aggregations and perhaps even things like: `SELECT 1, 'hello'` to work. That would be the ultimate test!
Happy to help with any Hasura integrations whenever you're ready too! Let's chat again soon. :)
Thanks for the proposition regarding Hasura integration. Happy to chat soon. Good luck with everything.
I also plan to rewrite the core to Deno. It will be relatively simple, but a bit mundane. ;)
Nestjs has been around or a while and support a ton of tranports not just graphql btw.
Do have particular complaints about Postgraphile that Nest has a better solution for (when constrained to GraphQL, which the author states is a goal)?
The issue here has nothing to do with how PostGraphile is implemented though, I've heard many people complimenting it for being better than alternatives. However the very idea of generating API from DB is problematic because that forces API consumers to think in term of DB operations not business processes. Most likely business logic will be leaked down to clients, or have to be managed in some convoluted way (Hasura actions).
> I just feel that writing business logic should not be something you have to do in a plugin of some tools or with knowledge of graphql (resolvers)
Business logic doesn't need to be written in the resolvers themselves (this is not generally good practice); instead your resolvers call out to your business logic layer as is the GraphQL way. For PostGraphile, in general the "business logic layer" is in the database itself (e.g. PostgreSQL functions, etc) which can be reused directly by other components of your stack (e.g. a REST API), but it doesn't have to be.
Is your issue more with how GraphQL in general works (resolvers calling out to the business logic layer), or do you feel that PostGraphile is adding layers of indirection due to an issue with the term "plugin"? If we called them "modules" would you be happier? Here's an example "plugin" that adds a new field to our GraphQL API, where the business logic is contained in a fictitious npm library and we just defer to that in the resolver - this is a common way of writing GraphQL schemas: defining the types/fields via SDL and the accompanying resolver functions: https://gist.github.com/benjie/68f55fa1bcc07e1cd7a8f49d423f1... . In PostGraphile we handle this through plugins because it allows you to mix and match (should you wish) different ways of building your schema (code-first, SDL-first, etc), and it allows you to do full-schema transformations if you wish. An example of full schema transformation is the PgOmitArchived plugin https://github.com/graphile-contrib/pg-omit-archived which adds "soft delete" support to everything in your API with a minimum of fuss - by default soft deleted things are hidden, but you may specify for soft-deleted items to be included, or shown exclusively, using a GraphQL field argument.
> is it really more productive
I suggest you ask our users why they love us; I suspect you'll find the massive increase in productivity is one of the main reasons.
> is it robust, now that your business logic layer is intertwined with your API layer
As mentioned above, this needn't be the case; yes, it's robust.