Next-generation web framework Teo, supports Node.js, Python and Rust | Hacker News Reader

Next-generation web framework Teo, supports Node.js, Python and Rust

teodev.io

92 pointsvictorteo44 comments

Just realized that the OP is also the lead developer. Congrats on launching!

I think you can position the product better. The hero text is "Next-generation web framework for Rust, Node.js and Python.". This doesn't convey much to me. Is this a framework that works for all these languages? And most importantly, why would a developer use Teo over native frameworks for each of these languages.

Yeah, I was confused about this, too.

The text is updated on the website. And it's not next-generation anymore.

Personally I understood what the phrase "next generation" was supposed to mean, that it's a new and better way of doing things, a new paradigm. But I guess it's a bit overused, like the word "simple", that people have a cynical reaction to it. Anyway, I think the concept is refreshingly clear, it looks like it has a lot of potential. Congrats on launching!

Nit: I'd change "Working in progress" to "Work in progress", it's more common to see the latter wording.

Thanks! I update it.

Thanks! I will update the hero text.

Looks very promising, congrats! I would remove the claim on the “Why Teo?” doc page that claims Teo is “Bug Free”. That’s an outrageous and impossible to achieve claim that turns people off.

Looks interesting. One suggestion, don't make data validation and authnz an after thought.

Something I'm missing from all these automatic API generation frameworks from schema is having different complex data validation rules for creating, updating and eventually deleting. It is nice to put simple data type constraints on fields, but is infinitely more useful to have a DSL that can express complex logic: field X cannot be Z when field Y and W have value V and U respectively. Or when mass inserting/updating validating that the aggregate of input field Z is greater than X or the aggregate is not already in DB. Same thing for relationship.

Laravel validation rules is the closest that comes to this kind of input validation, but Laravel doesn't provide automatic API generation.

Hi @rrgok, Teo supports builtin and extendable data validation and authentication rules. The feature is called pipeline. It supports very complicated type inference. See this: https://docs.teodev.io/concepts/components/teo-schema/pipeli...

This is fantastic.

At the same time, there's an ecosystem beyond just the web framework, where rapid iteration is helping a developer write once but leverage multiple tools.

For instance:

  - FastAPI
  - Starlette
  - pydantic
  - sqlmodel
  - postgres

Here's an example discussion for building the full stack yourself: https://medium.com/@lawsontaylor/the-ultimate-fastapi-projec...

The value comes from the sort of community-agreed data model:

Why: https://docs.pydantic.dev/latest/why/

Datamodel code gen: https://docs.pydantic.dev/latest/integrations/datamodel_code...

With this at the core, then API contract, doc, DB, test, and SDK generation are at hand, not to mention easier integration with all of these other projects. And now with

Observability: https://pydantic.dev/logfire

I find no hits on the terms `pydantic` or `openapi` in your docs. Given your choice to include Python as one of the three supported languages, do you have a plan to tie into Pydantic or implement a bridge?

Hi @Terretta, I plan to generate OpenAPI output for HTTP clients like Postman to import and read. We have things like FastAPI, Starlet, pedantic, sqlmodel and Postgres in Teo. The only thing we lack of is the debugger web interface which we could use Postman after exporting OpenAPI output is implemented.

The logfire is pretty cool and in the future, it will be implemented in Teo's way.

Thanks for the reply.

To be more clear, it's great you have a similar option for each of these, but having things similar to them isn't the same as having the actually same model that everything else in the ecosystem understands and plays well with.

Or, are you saying, under the hood, you're using literally the same? The docs make it sound as though you're reinventing all these wheels (pardon the Python pun).

They are similar things. The wheels are reimplemented to suit Teo's architecture.

Looks interesting, will check it out. Does this have auth built in as well? RLS? I love any tool that speeds up small projects.

Hi @e-clinton, it does have auth builtin.

A web framework that supports 3 different languages/runtimes is quite nextgen for me! Better than calling a framework integrated with LLM next gen.

Congrats on launching.

Do you target big projects with heterogeneoud team ?

Is that the problem it's trying to solve?

Both big projects and small projects are targeted. It doesn't sacrifice functionality while provides speed up.

Some interesting ideas here, but urgh, the Rust examples... that is really not things should work...

It seems to work by registering callbacks into a context by name, eschewing any sensible typing relation with the schema. I assume the scaffolding code would lead to panics at startup, or worse, on invocation.

The way to do this would be generating traits and have the user implement the trait.

That makes sense. I fill fix panics and take this consideration into the next major version.

personally, I prefer the style of raku Red ORM https://raku.land/zef:FCO/Red

    use Red:api<2>;
    
    model User is rw {
        has Int       $.id          is serial;
        has Str       $.name        is column;
        has Str       $.email       is column{ :unique };
        has Str       $.password    is column{ :nullable } is rw;
        has DateTime  $.created-at  is column .= now;
        has DateTime  $.updated-at  is column .= now;
    }
    
    my $*RED-DB = database "SQLite";
    
    User.^create-table;

Looks exactly like smithy?

Well, I just looked at Smithy. And they quite differ. Teo is just an HTTP framework like fastify, express, koa, flask and fastapi. It has a schema language and a builtin ORM, which make it quite similar to GraphQL and Prisma.

Title could have read "Schema-driven web server framework for Rust, Node & Python". Idea has merit -- much of the implementation is in the schema and therefore language agnostic. And you can choose from three languages. Using "next generation" or "modern" is now a signal (at least to people like myself), that something is just a reimplementation of an old idea with new syntax.

I agree, my connotation of "web framework" is that it competes with Next.js or Remix or something. This seems like a schema-driven ORM a la Prisma, plus API layer. In other words, you could conceivably use it alongside a "web framework".

I would lean in on the unified schema aspect, I think that distinguishes it from a lot of web-focused ORMs. It actually feels like it could be compared against GraphQL given the schema and API features.

Of course, that leads me to wonder about the hairy stuff: permissions, rate limiting, schema evolution, etc.

Hi @tkzed49, Teo supports custom route handlers and routing middlewares. Teo is a web framework with a builtin ORM. There are builtin permissions, too. You can use it or implement your own. Teo supports database auto migration.

I like the idea and it's not specific to web development. So many times in my career I've wanted to share a schema and data types of an application across languages that need to communicate with each other. For example, a C script that generates JSON data to be read in a Python notebook into the same data types.

I'm aware that serialization frameworks like protocol buffers do this, but they usually come with a whole lot of other baggage, dependencies, hit-or-miss language support, and clunky APIs. I want something more lightweight that allows me to start developing an application by developing its schema, without it being tied to a specific serialization framework or language implementation.

Tangentially related: I needed to share some binary data from Java to python. Didn’t want to pull in protobuf (for probably mostly bad reasons), so I wrote a writer implementation in Java, then asked gpt4o to write the python reader. Worked like a charm - it produced a great starting point then refactored it to my liking.

All that to say: with chatbots being able to implement “the other side”, it really made it a lot easier to just whip up a custom schema and not really worry too much.

(Helped that it was a one off in my case, unclear how well this would scale to real world production usage)

JSONSchema is good for this IME. It can model 99.9% of usual models, supports generation & validation for most major languages. It's also part of OpenAPI, useful if you expand your modelling to REST APIs.

https://json-schema.org/implementations

how can i auto generate api code with this

You would use OpenAPI (formerly Swagger) [1] for that, which includes JSONSchema for data types but also adds specs for defining REST apis. There are plenty of generators and other tools that work with OpenAPI [2]

[1] https://www.openapis.org/

[2] https://openapi-generator.tech/

Bonus points if you can just build the tooling to work with some emerging standards at different levels of the stack. A few relevant ones that come to mind would be:

- CBOR for the on the wire format

- CDDL for schema design of CBOR objects.

- WebTransport as the API you use on top of HTTP/3 for actually moving bits of data back and forth between client and server.

The nice thing about that approach to is that it’s in no way tied of any kind of language or other architectural patterns that larger frameworks tend to force you into. The beauty of the standards process I guess.

If someone could put together a great API design experience that wrapped all of that up with cross language code generation like Protobuf / gRPC I would switch tomorrow.

Links for those (like me) who didn't recognize the acronyms:

CBOR - RFC 8949 Concise Binary Object Representation

https://www.rfc-editor.org/rfc/rfc8949.html

CDDL - RFC 8610 Concise Data Definition Language (CDDL)

https://datatracker.ietf.org/doc/html/rfc8610

Hi @hliyan, I will update the words.

As someone who worked with Groovy/Grails when it came out (because Ruby on Rails was hot and the JVM wanted in too) - this looks neat, but "next generation" made me chuckle.

I will remove the "next-generation" thing.

Looks like an alternate way of ORM with http handling. Where's the next-gen part?

Well duh, it's built in Rust!

Reply on news.ycombinator.com