lonelyteapot / open-transit-old-prototype

Transit-at-Hand-Backend

open-transit-old-prototype's Issues

Provide static Network information

A transit network is where all routes are somewhat connected. It may correspond to a city or a region.

Fields

• id
• name
• routes in the network

Provide static Route information

Fields

• id
• number AND/OR name
• every stop along the route
• starting and ending locations
• transit type(s) that usually runs on the route
• transit company(s) that usually serve the route

Possible types of routes

• 2-way, runs from start to end, then from end to start
• 1-way, runs from start to end
• half-loop, runs from start to start, partially overlapping in opposite directions
• full-loop, runs without end, MAY overlap in opposite directions

Actually, any type of route can have multiple important (start/end) stops, where passengers must disembark either always, or when a vehicle enters/exits the service.

Implement a GraphQL API

The only API will be public at least for now.

I consider omitting REST and only do GraphQL, since the transit data is heavily interconnected.

Framework choice

strawberry

• Code-first
• Based heavily on dataclasses and type hints -- good experience but encourages couping
• A rolling release, well-tested in CD
• Version 1 coming, with promises of stability and interface improvements
• Lacks needed extensions

graphene

• Code-first
• Mainstream solution
• Very stable, but infrequently updated, lacks maintainers

ariadne

• Schema-first (the only usable framework)
• Infrequently updated and lacks maintainers
• Doesn't feel solid
• Has good extensions

---

I really want to go Schema-first, but ariadne is not a good choice.

Best practices

Model as a graph.
Use relay's Connections on everything.
Plan for the future without versioning.
Return Payload types from mutations.

Good tips: https://graphql-rules.com/

---

Auth and other protection is not needed yet.

Implement an ASGI app

An ASGI app (Asynchronous Server Gateway Interface) is going to be the main server.
The GraphQL API is going to be served through it as well.

Framework choice

Both of these are very performant and provide good developer experience.
Key feature is the easy creation of JSON APIs and OpenAPI docs, but we probably won't need it much.

FastAPI

Stable and proved by the industry.
(My opinion):
Seems to be a bit bloated.
The main maintainer is very protective and doesn't approve most pull requests.
He also doesn't support some of his other projects and they become outdated.

Starlite

Basically a much better version of FastAPI.
It enforces good practices that make the code much better.
It's not really well-known, unfortunately.
It's very open to the community and frequently updated.

Create the database schema

We're going to use PostgreSQL as it's the most universal and commonly used.
Nothing complicated yet.

ORM choice

Prisma

• Modern and quickly evolving
• Single source of truth - the schema file. All Python code is auto-generated
• Migrations are very easy
• Clear and simple interface. HOWEVER, Python is not supported officially, it's mainly made for JS
• Asynchronous by default
• Good tools are starting to pop up

SQLAlchemy

• Proved and stable
• The one I'm much more familiar with
• Slow update cycle, but it's enough
• Migrations are streamlined but not great
• Model with Python classes instead of a specific schema language

Provide static Stop information

Fields

• id
• name
• geolocation
• routes that go through the stop

Not sure whether a stop should belong to a network or not.