Closed bl-nero closed 4 years ago
What we plan on doing:
What we still need to know:
The website and app will have different backends. This is because the website needs identifiable information to schedule, and the app is deliberatey never given access to such information.
We're more or less settled on ES/AWS for the app
3 and 4. @bl-nero will be better positioned to answer this?
Let's start with a typical REST API, JSON payloads, nothing particularly fancy. I'd like to use the dev server's built-in proxy for development, and in production, we should use a HTTP proxy that allows us to view both the API and UI from the same domains; this way, we'll avoid having to use CORS for requests. This way or another, it shouldn't have too much impact on the scaffold.
Django on Apache? Hell, I don't know. I've always been using Gunicorn, but then, I've only used Flask, so I don't know what's the typical option in the Django land. Up to you. I guess that it can be easily changed in future, right?
On a side note: please remember that we're only adding a scaffold to quickly code an endpoint or two; let's worry about deployment after we commit the first PR.
So Django by default uses a light weight wsgi server. In prod we can simply use a wsgi based apache deployment, so we shoud be fine.
Even I extensively use flask which is very convenient. I agree on the REST API communication protocol will be ideal between front end layer and app layer.
https://www.valentinog.com/blog/drf/
This seems like a really good start in writing a Django backend and gluing it to the React frontend. TL;DR: Write a Django REST backend and wire it to React using React routing.
Decide on the server technology stack and create a basic "hello world" server.