full-stack-fastapi-postgresql VS openapi-generator

I've just recently switched to a structure that follows Netflix's Dispatch application after starting with https://github.com/tiangolo/full-stack-fastapi-postgresql and it feels way better and organized.

I would encourage you to take a look at this repo: https://github.com/tiangolo/full-stack-fastapi-postgresql This is a boilerplate of an application made with fastapi, prepared by the creator of the fastapi himself. You can even set it up yourself locally and have a look how it’s organised. I know it has a lot of different services included, but I find the fastapi part itself to be well thought. Inside the api directory you can notice another folder named api_v1, so you can have multiple versions of your API routes when needed, with the general code in other places that is more generic and can be reused in all your different API versions. The schemas are separated from the models and models itself have different classes depending on what you would actually like to do with the data. The migrations are managed with alembic based on schemas rather than models itself. The settings are a python class that implicitly reads the .env file in your project’s directory. And many, many other interesting patterns to explore. Too much to write in one comment to be honest.

Have a look at Full Stack FastAPI and PostgreSQL - Base Project Generator

While that is a good base, it can be a bit outdated in places. I would suggest checking out this issue on the topic

Hi, earlier this year I built a project using the official FastAPI full stack example. While working on my project, I realised that the FastAPI ecosystem has matured a lot since that template was created and many things that I ended up writing code for was already solved by others. And I didn't want to keep reinventing the wheel.

I'm glad you're liking FastAPI!

You could check the official project generator, it includes a simple Vue.js front end: https://github.com/tiangolo/full-stack-fastapi-postgresql

Although I'm currently using React with TypeScript and hooks, and it's a great development experience. I plan on adding it to the project generator later.

https://github.com/OpenAPITools/openapi-generator

Reviews are mixed though.

I've tried using OpenAPI a few times, it's been...lackluster... I probably won't use it again.

Here are my gripes:

1) For me one of the biggest selling points is client code gen (https://github.com/OpenAPITools/openapi-generator). Basically it sucks, or at least it sucks in enough languages to spoil it. The value prop here is define the API once, code gen the client for Ruby, Python and Scala (or insert your languages here). Often there are a half dozen clients for each language, often they are simply broken (the generated code just straight up doesn't compile). Of the ones that do work, you get random PRs accepted that impose a completely different ideological approach to how the client works. It really seems like any PR is accepted with no overarching guidance.

2) JSONSchema is too limited. We use it for a lot of things, but it just makes some things incredibly hard. This is compounded by the seemingly limitless number of version or drafts of the spec. If your goal is interop, which it probably is if you are using JSON, you have to go our and research what the lower common denominator draft spec JSONSchema support is for the various languages you want to use and limit yourself to that (probably draft 4, or draft 7).

Check out https://openapi-generator.tech/

I thought about publishing NPM and PyPI packages once I clean it up a bit. Until then though you can autogenerate a Python client using the OpenAPI code gen tool. That's what I would be doing to create the package anyway.

How about this; there's some rust samples in there - https://github.com/OpenAPITools/openapi-generator/tree/master

Unless you are trying to build some kind of offline mode, all your frontend should know about the backend is the response schema. You could feed an OpenAPI spec to something like https://openapi-generator.tech/ and generate a Dart client. Then, whenever some endpoint changes you will have to regenerate the client. Bonus points for doing API versioning.

Take a look at OpenAPI generator (https://openapi-generator.tech). You define your REST schema, and it will generate server stub code for you (flask and fastapi are supported, among others). It's not pretty, but it'll get you up and running quickly and you can see which one you like better.

While I could have written out a full API to talk to the Forem API, this would have taken a long time and I had an OpenAPI spec document, so I used OpenAPI Generator which can pretty much instantly generate a full API integration, just from the OpenAPI spec. While I'm using C# and .Net 6, this tool has a pretty large list of supported languages, so if you wanted to code something similar, you could absolutely use your language of choice, rather than C#.

I was thinking of using OpenAPI Generator to generate a Rust server stub for me. Problem: the generator generates a crate with numerous modules and a rather complicated manifest, not a single module that I can straightforwardly include!. How do I integrate this into my project, then? I can download and run the generator in build.rs, but Cargo doesn't support depending on a crate generated by the build script, so how do I actually use it?

I have a project using openapi-generator. Our system works well, and we have a number of custom mustache template overrides. That said, janephp looks appealing to me as it's php native, would remove java dependencies, and be fully manageable through composer.