Show HN: Kretes – Build full-stack applications in TypeScript and PostgreSQL | Hacker News Reader

Show HN: Kretes – Build full-stack applications in TypeScript and PostgreSQL

kretes.dev

81 pointszaiste24 comments

Hey HN, author here. Kretes is a tool for building full-stack applications in TypeScript and PostgreSQL with a goal to provide an integrated, battery-included and open-source solution for web development. It combines a web framework - similar to Rails, Django or Laravel - with a UI being built on top of the VS Code editor. It comes with a (eventually large) standard library of built-in modules that are developed in a coherent way e.g. authentication, authorization, admin panel [1] etc.

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 started as a way to arrange my knowledge around JavaScript. Inspired by the past, I decided to replicate to some extend what Sun Microsystems did in ’95 with the Self programming language (a project I find underrated and ahead of its time), but using modern, popular tools such as JavaScript/TypeScript, VS Code, WebAssembly, PostgreSQL, etc.

The project is in early alpha stage with the bus factor of (strong) 1. :)

Happy to answer any questions here or at oh@zaiste.net*

PS. I’m creating a todo app using Kretes on YouTube [2] 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.

[1] not yet public

[2] https://www.youtube.com/watch?v=rLAElFkRrWI&list=PLhXZp00uXB...

> I decided to replicate to some extend what Sun Microsystems did in ’95 with the Self programming language

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'd like to tightly combine a semi-visual programming editor, the tooling and the runtime/infrastructure into one «thing» as shown in this video [1]. You write a bit of code, you drag and drop another bit, and almost instantly it becomes «online» - the compilation / the deployment process are somehow hidden and the configuration is minimal. It just works, so you can focus on solving the actual business needs of your application - but that's a long term vision... ;)

I must mention DarkLang [2] 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

[1]: https://www.youtube.com/watch?v=Ox5P7QyL774 [2]: https://darklang.com/

This project looks very useful. Since you compare it to Django and mention it has batteries included i have a few questions I'd like to ask.

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.

Thanks for the kind words!

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 [1] 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 [2]. You have just one Node process for both front-end & back-end: in development I compile assets on the fly using ESBuild [4], 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 [5] - 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 [3] 5. I'm still working on the docs. I'll fix the things you mentioned right away.

[1]: https://github.com/salsita/node-pg-migrate [2]: https://github.com/vitejs/vite [3]: https://github.com/typeofweb/functional-orm [4]: https://github.com/evanw/esbuild [5]: https://sqorn.org/docs/about.html

Thank you for the very informed reply. I think your project has a great future if you keep working on it. A fully typed query builder sounds amazing, the weakly typed one of Django bit me once back when I was getting started with it.

Why does this depend on both Reactjs and Vuejs aren't they essentially the same thing?

Yes, they are essentially identical, it's about giving a choice. Also, those libraries focus (mostly) on the front-end part. In Kretes, I'd like to provide tools/methods that cover the whole stack so to speak. This is especially visible for newcomers. A Vue.js tutorial may show you how to build the UI, but then you need to figure out how to bring in and persist the data, or how to connect to an API, etc. This isn't to say that such article should cover everything, but I have an impression that the industry requires or rather forces specialization too early, i.e. before people have a chance to understand the big picture. Kretes is about arranging different pieces together so that they are ready to use right away, even if you know how to configure them on your own, you don't need to and can focus on solving the actual business needs of your application.

Disclaimer: As the project is in early alpha, this promise is not yet fully fulfilled. :)

Congrats!

I see that Kretes uses Sqorn [1] 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?

[1] https://github.com/sqorn/sqorn

Hello Tanmai :) Yes, exactly. It's not typed and also not actively maintained. The goal is to have a fully typed query builder that's adapted only to PostgreSQL. Here's the preliminary work for that [1]. I would also like to find a way to fully integrate with Hasura

[1]: https://github.com/typeofweb/functional-orm

Hey Zaiste! I missed your name as OP :)

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. :)

Yes, our discussion a few weeks ago pushed me further to explore this topic. JOOQ is exactly what I'm looking for JavaScript/TypeScript. It's just a matter of having enough time ;)

Thanks for the proposition regarding Hasura integration. Happy to chat soon. Good luck with everything.

That Postgres query library could be the most broadly useful part of the whole stack. Also looks like a big job! Best of luck!

Sounds very promising. I try it out tonight.

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.

Thanks!

The environments introduced by Smalltalk, Self - and Racket, if we talk Lisp ;) - are one of major inspirations for this project. Another idea is to focus more on the JavaScript prototypical nature, instead of adapting solutions or design patterns from programming languages such as Java or C# as OOP is different in JavaScript.

The project, however, is in early alpha, still far from being close to a programming environment per se.

I'd be interested in contributing to this project. I'm going to poke around the codebase and see if there's anything I'd be able to help with. Reply if you have anything in mind!

Wow! That would be awesome. I'd like to finish with the on-the-fly compilation that uses ESBuild. This approach is similar to Vite and Snowpack. I wanted to integrate it with React/Preact and Solid.js in the next few weeks. Any help with that would be appreciated.

I also plan to rewrite the core to Deno. It will be relatively simple, but a bit mundane. ;)

The choice of both Tailwind and Postgraphile makes me want to throw up. The two things are on the top of my hyped techs list. They're geared toward PERSONAL productivity at the expense of maintainable styles and good API design, respectively.

Nestjs has been around or a while and support a ton of tranports not just graphql btw.

Nest is popular in some of the Angular circles but the projects I've seen use it are just as unwieldy as any other language / framework with out disciplined devs.

Do have particular complaints about Postgraphile that Nest has a better solution for (when constrained to GraphQL, which the author states is a goal)?

It's just a framework that helps you productive with enough options to not be opinionated (such as constrained to graphql). I would not use a "framework" myself though. The only thing in frameworks that I used to find useful was the IoC container but then I realised composition roots are enough.

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).

PostGraphile maintainer here; what you’ve said is not really true for PostGraphile - we give you a huge toolbox of ways to customize, shape and extend your schema so it’s designed for consumers to consume rather than just being a way of exposing your database over GraphQL (which I agree is not necessarily the right goal in many cases). It does encourage you to put your business logic in the database, but you can also do logic in JS/TS if you see fit with our powerful plugin system and range of plugin factories for common tasks, such as makeExtendSchemaPlugin for adding your own types and resolvers. It constructs a GraphQL schema using the reference implementation so you can then use the schema with other tools if you like. For an example GraphQL schema that’s client focussed, see: https://graphile-starter.herokuapp.com/graphiql . I care deeply about building high quality GraphQL schemas; this is one of the reasons I contribute to the GraphQL Spec itself.

I have not used PostGraphile myself so I should not have used such strong words about it. 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). Sure it can be done but at the end is it really more productive with that many indirections? More importantly is it robust, now that your business logic layer is intertwined with your API layer?

No worries, I think judging things we're unfamiliar with is very human - it's necessary to protect our own time because we can't afford to research _everything_. We just need to be careful to not share these quick judgements as if they are well researched opinions.

> 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.

Thanks, your answer definite gives me some confident in trying PostGraphile for my next project. I agree that "plugin" can just be how we call a thing, it doesn't necessarily entail a heavy abstraction or some sort of lock-in. I'll look further into your suggestions.

Reply on news.ycombinator.com