Discuss the roadmap

[bradleybeddoes]

We're going to trial using this issue as a place for the community to discuss the roadmap for the Gotham web framework.

Where we can we'll split out directions that we've agreed on as useful into individual issues for further discussion, implementation and eventually milestone assignment.

Discussion here should not be limited purely to technical components, we're also interested in framework ergonomics, learning resources, documentation and so forth.

Please feel free to drop by https://gitter.im/gotham-rs/gotham if you'd like to run an idea past the community before adding it here.

[spacekookie]

I think there are a few key points that differentiate a framework like Django or Rails from "microframeworks" like express.js or pretty much all current Rust frameworks: the amount of boilerplate to be written by users to get started.

• Getting started and onboarding
  • Does the framework generate template apps?
  • Can a simple "Hello World" be generated?
• Database integration
  • Can a database be included with trivial work required?
  • Does the framework handle migrations?
  • How does the framework handle models?
• User management
  • Is there default user model that can easily be used?
  • Is there a simple way of handling authentication in 1-2 lines of code?
  • Are thjere built-in roles and permissions that can be extended (See Django again)
• Opinionated & Implicit
  • Is a certain folder structure required/ enforced?
  • Are certain naming conventions required/ enforced?
  • Is the framework more explicit (Django) or implicit (Rails)?

I obviously have opinions on all of those points :wink: Most importantly I think a good web framework is made by it's integration of an ORM!

But I'm more curious what the community thinks and where it wants to take gotham.

[dsvensson]

Contrary to the comment above I value Gothams current minimal state and think it would be much wiser to continue focus on an interoperability-friendly contact surface that allows Gotham to blend naturally with for example Diesel (something that already exists, with an example on the way in https://github.com/gotham-rs/gotham/pull/126). Stating that a specific ORM is what is to be used with Gotham, would imho hurt the project, as today's favorite data layer is something that change over time, compared to the design decisions that underlie Gotham that are less volatile. More examples, blog articles, and tutorials in other forms would be a better approach.

One future direction in my eyes would be to make the routing more specified. IntoResponse exists today, which allows a handler to return a type implementing this trait. I may very well have missed something, but if there isn't something like a BodyExtractor trait, that would be a nice addition, such that handlers are passed data in the correct form from start, just like PathExtractor and QueryExtractor.

This feels like a very fundamental thing to have, so perhaps there are good reasons for it being left out, when (Path|Query)Extractor's are already in place.

Given that it makes sense, with something like a BodyExtractor in place, there would be enough type details in place to be able to generate something like JSON-Schema/OpenAPI/Swagger automatically. I would prefer if the metadata was available for an external library to implement this, as these kinds of things tend to be trendy concepts changing over time. Exposing such a schema is a bit of a chicken vs egg thing as well. Can it live under the router path, or must it be a sibling to the router root? Not really sure what is the most common practice here.

The various schema-concepts have the ability to expose documentation for the REST API as well, so maybe there ought to be room for attaching metadata to the various moving parts, something that would be made available by introspecting the router. So you only have documentation for types and routes at a single place, rather than type documentation in both the code, and in some separate schema description file.

Another way of looking at the schema-concepts is that they could be implemented at a higher level, so you actually have the schema defined in a file, and generate both a schema endpoint, and the rest of the router. This approach would allow it to be a completely separate library. It would however have the downside of potentially having documentation for types in both the schema file, and in the source code.

A natural inspiration being servant-swagger.

[spacekookie]

@dsvensson Just something I want to immediately respond to because I think you misunderstood me there.

Contrary to the comment above I value Gothams current minimal state and think it would be much wiser to continue focus on an interoperability-friendly contact surface that allows Gotham to blend naturally with for example Diesel (something that already exists, with an example on the way in #126). Stating that a specific ORM is what is to be used with Gotham, would imho hurt the project, as today's favorite data layer is something that change over time, compared to the design decisions that underlie Gotham that are less volatile. More examples, blog articles, and tutorials in other forms would be a better approach.

I'm not suggesting that gotham writes it's own ORM from scratch. That would be quite silly. I mean that components should exist to make integrating things like diesel trivial. That means that gotham takes care of integrating things like diesel, r2d2 etc. Because as a user I just want to be able to use a database, without having to worry about thread-pools or whatever.

This would then also include gotham making sure that diesel is compiled with the rust-migrations flag which is being added by diesel-rs/diesel#1573 :wink:

And I think that's probably the biggest difference between web frameworks and web toolkits.

[anderejd]

+1 for swagger/OpenAPI generator, that would be a killer feature.

[bradleybeddoes]

I believe the discussion here about 3rd party components is largely saying the same thing. It also happens that it mirrors the original Gotham plan. That is having a having a flexible, non magical core with extension points that allows integration with other components. The extractor, Handler, Middleware and Pipeline concepts within Gotham support this right now, in time there may be more.

Standardising some of these implementations makes sense and we're a tiny way down that path which can be seen in the early (non finished or prod!!) dev work we have done for Diesel the discussions being had for Redis and the discussion for Body extraction (or form handling depending on your viewpoint).

For niche integrations I am hopeful that the community will provide and support implementations over time.

Perhaps this places Gotham somewhere between a framework and a toolkit, I'm personally fine with that.

Overall clean Gotham API's, automated testing, detailed examples, documentation and the wider community will be key in ensuring these pieces are easy to use and plug together in the longer term.

[bradleybeddoes]

@dsvensson I think there is sufficient interest to spawn the ideas you have around metadata exposure for JSON-Schema/OpenAPI/Swagger into a seperate issue as a potential future issue. Would you like to create that so we could continue the discussion on that specific concept there?

You'll also be interested in #11 which is discussing body extraction and would be a pre-requisite as you've noted. Any thoughts about body extraction itself would be very welcome in that issue.

[bradleybeddoes]

@spacekookie I have a private spike which i'll finish up and make public at some point soon that, if nothing else, will be a useful basis to further discuss gotham project generation.

I like the user management idea but having some previous experience in this space it is a topic that needs a lot of thought and ultimately tradeoffs. Are others interested in such an approach?

[gonzofish]

Let me start of my saying that, so far, I really like this project.

I think, @bradleybeddoes, that you're saying Gotham's intent is to keep hooks/implementations between 3rd parties & Gotham out of the core, correct?

[bradleybeddoes]

@gonzofish flexible extension points in the core (which already exist but may be added to in the future) with this project then also implementing/supporting a small number of additional crates, using only those extension points, for common 3rd party components (i.e. Diesel/Databases, Redis).

We've started this process at https://github.com/gotham-rs/gotham/tree/master/middleware

[spacekookie]

@bradleybeddoes @gonzofish I mean, the points I listed and wanting to be flexible and extension based aren't mutually exclusive.

Looking at ember.js for example, the core of the framework is rather light. But doing an ember new will install a lot of extensions for things that almost everybody needs. And I think database integration and basic user management/ authentication is something that should be trivial to setup.

Either in the code itself or via some build pipeline :wink:

[gonzofish]

So the support of additional crates, does that mean Gotham will have its recommended integrations (like Diesel) but you can swap them out? I guess my bigger question, to relay off of @spacekookie, is whether the approach is more full framework than library-like (ie, Django vs Flask)?

[bradleybeddoes]

@spacekookie they absolutely aren't. My apologies if I gave that impression, it was not intended.

By taking the extensions approach and combining that with project generators/templates that provide a quick start for 'common' use cases I believe we can get the best of both worlds without strictly being either.