
Show HN: Kretes – Build full-stack applications in TypeScript and PostgreSQL - zaiste
https://kretes.dev/
======
zaiste
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...](https://www.youtube.com/watch?v=rLAElFkRrWI&list=PLhXZp00uXBk5hnHEIAFl74mZyLrVKKJAD)

~~~
debaserab2
> 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?

~~~
zaiste
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](https://www.youtube.com/watch?v=Ox5P7QyL774)
[2]: [https://darklang.com/](https://darklang.com/)

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

~~~
zaiste
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](https://github.com/salsita/node-pg-migrate) [2]:
[https://github.com/vitejs/vite](https://github.com/vitejs/vite) [3]:
[https://github.com/typeofweb/functional-
orm](https://github.com/typeofweb/functional-orm) [4]:
[https://github.com/evanw/esbuild](https://github.com/evanw/esbuild) [5]:
[https://sqorn.org/docs/about.html](https://sqorn.org/docs/about.html)

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

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

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

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

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

------
tango12
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](https://github.com/sqorn/sqorn)

~~~
zaiste
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](https://github.com/typeofweb/functional-orm)

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

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

------
MH15
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!

~~~
zaiste
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. ;)

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

~~~
leetrout
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)?

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

~~~
BenjieGillam
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](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.

~~~
nsonha
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?

~~~
BenjieGillam
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...](https://gist.github.com/benjie/68f55fa1bcc07e1cd7a8f49d423f1416)
. 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](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.

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

