Split front-end (website) and backend (API endpoints)

[leomeloxp]

No description provided.

[cuducos]

Sorry, but what exactly you mean by that?

Currently Jarbas serves the site at / and serves the API at /api/.

If you reach /api/ as a human via browser Django REST Framework offers a human user-friendly UI, but if you reach it as a machine, via AJAX, curl etc. you get plain JSON:

$ curl http://jarbas.datasciencebr.com/api/document/\?document_id\=5925678
{"count":1,"next":null,"previous":null,"results":[{"id":32782,"document_id":5925678,"congressperson_name":"CARMEN ZANOTTO","congressperson_id":164360,"congressperson_document":477,"term":2015,"state":"SC","party":"PPS","term_id":55,"subquota_number":5,"subquota_description":"Publicity of parliamentary activity","subquota_group_id":0,"subquota_group_description":"","supplier":"SIONEI RICARDO LEÃO DE ARAÚJO - MÍDIAS E IDENTIDADE","cnpj_cpf":"23782893000170","document_number":"0002","document_type":0,"issue_date":"2016-03-01T00:00:00","document_value":"5400.000","remark_value":"0.000","net_value":"5400.000","month":2,"year":2016,"installment":0,"passenger":"","leg_of_the_trip":"","batch_number":1267747,"reimbursement_number":5363,"reimbursement_value":"0.000","applicant_id":2433,"receipt_url":null,"receipt_fetched":false}]}

Yet the Jarbas itself is split in three apps:

• jarbas/core: core models, commands and URL configuration
• jarbas/api: the API (depends on jarbas/core)
• jarbas/frontend: the SASS & Elm front-end (independent of the other two apps, dependent on Django to compile SASS to CSS and Elm to JS)

As the front-end is backend agnostic it could have its own repository and its own compile & deploy isolated from Django. But I think that as we're deploying to the same server, and as we already miss a devops to look after it, keeping it (by now) in this repo is a good choice.

But I'm still not sure what was your point was about — would you mind expanding on it so we figure out how to improve Jarbas?

Many thanks,

[leomeloxp]

Oh wow, I had created this issue without a description. I then typed the whole description and probably forgot to submit/save 😂 Sorry for the totally unclear question 😑

Yeah, I meant breaking Jarbas into 2 (but as you now highlighted 3) repositories to make it easier to maintain.

Following up on your comment, I think it makes more sense to keep it all as a single repo for now, as there're no DevOps strategies in place. But to eventually break them up could be nice.

Lastly, I believe some of the server side rendering for the front-end is handled by Django/Python, correct? Would there be any motivation for adding some React on the front-end and maybe handling the data changes through AJAX or even server-side JS. At least for the React part, I believe it could make things easier when we came across into adding new functionality(eg, some advanced filtering of data) or even just improving bandwidth (sending across only JSON rather than full page markup after first page load).

That's more or less what I had in mind. Happy to keep the discussion going 🙂

[cuducos]

1. Split backend & front-end

Yes, in the future it makes sense. Now I'm afraid just adding nginx configs, shell scripts, instructions and git hooks to contrib/ will make it a bigger mess — i.e will create technical debt.I really would like to see a proper solution for that. Maybe @luiz-simples can help us with Docker and stuff… and then we can afford a more solid infrastructure for development, provision and deployment — that's the perfect time for splitting the repo I guess: something like jarbas-api and jarbas-frontend.

Just a minor detail: no need to split in three. Backend and front-end is enough. It is a merely a Django architecture decision to keep some stuff in the core (jarbas/core) and some stuff in the API (jarbas/api), but they should be together on the backend repo.

2. Front-end

I believe some of the server side rendering for the front-end is handled by Django/Python […]

No. Python backend is merely compiling files (from .sass to .css and from .elm to .js). We could literally deploy a HTML together with the .css and .js to a S3 instance (I mean, something with no backend at all) and that would work.

Would there be any motivation for adding some React on the front-end and maybe handling the data changes through AJAX or even server-side JS

100% of the data changes is managed in the front-end already (no UI rendering in the backend, no JS in the server-side).

for the React part, I believe it could make things easier when we came across into adding new functionality(eg, some advanced filtering of data) or even just improving bandwidth (sending across only JSON rather than full page markup after first page load).

All that is currently handled through Elm. We are literally just sending across only JSON rather than full page markup after first page load already : )

[cuducos]

Closed by inactivity