Future front end developments about priceandnutritiontrackingsystem HOT 6 CLOSED

As an example, I threw together an API design document for a RESTful API on Ingredients. The file is available in a branch on my fork, here.

The file is an OpenAPI spec document, and should be compatible with any OpenAPI editor. I created it using Stoplight, which is freely available online. You could load up this file into any OpenAPI viewer or documentation generator to get an easily viewable API. A quick search brought up this page, where you could paste the link to the raw spec file (https://raw.githubusercontent.com/AustinGrey/PriceAndNutritionTrackingSystem/3-ingredients-api/reference/PANTS-API.v1.yaml) and begin viewing it in an interactive format. This probably isn't the best viewer out there, but just what came up.

from priceandnutritiontrackingsystem.

Thanks for the work you've put into the API/Frontend.

My plan is to use Django REST Framework to add the API - there was a little experimental code at /ingredients/filter/ , testing an endpoint that could filter ingredients by various properties, like having calories above or below a certain amount.

The README is a bit outdated/misleading - I'm happy to continue to tweak the Django template frontend further, but ultimately it's probably more practical to focus on an API that can be used for
dedicated frontend clients that can provide a richer interface.

I haven't been prioritizing the API because I wasn't ready to start working on any such clients myself, but if you are interested in doing so I can create the serializers using DRF easily. I'll start with the
Diary (as this is already per-user, and gets the most frequent changes anyway).

The Ingredient API looks good but the DB schema should be updated first to to allow per-user Ingredient/Recipe objects to be created and edited - adding the user Foreign Key can be done pretty easily but the views will have to be set up to present both the global and per-user items. I'll try and get that done soon as well.

from priceandnutritiontrackingsystem.

Commit 56baff2 has added an API for diary - if logged in http://127.0.0.1:8000/api/1/diaryfood/ should be browsable HTML and http://127.0.0.1:8000/api/1/diaryfood/?format=json should give the raw JSON.

from priceandnutritiontrackingsystem.

Okay I took a stab at using the API to create some prototype front ends. There is now an 'Ingredient Manager' (branch 4-frontend-prototype, commit AustinGrey/PriceAndNutritionTrackingSystem@59b5df6) prototype that allows basic CRUD for ingredients. It raised a few questions:

1. Authentication: right now I'm using hard coded basic auth, passing in a user name and password with each request. While this is secure if the server is hosted locally or over https, it is not if hosted over http. What Authentication scheme were you envisioning?
2. CORS: on your branch the API is only accessible from the same host/port. If I run the server at 127.0.0.1:8000, and my frontend on 127.0.0.1:8001, then requests are blocked because CORS is not set. My branch installs a CORS package for django, and then sets CORS headers on all /api/* endpoints - I don't see a way around this if the api is meant to enable separate front ends.
3. Searching/Sorting: right now the only filtering options are exact match by object key (e.g. name=salt, name=sa, and name=sal return nothing, but name=Salt returns the Salt ingredient). I added options for partial matches under search key (eg. search=sa returns the Salt ingredient), and sorting on all columns by default
4. Right now the API errors when attempting to create or update an ingredient with tags, because there's no method to set the tags, only to read them. I know the API is not done so I only mention this if you choose to try out the prototype.
5. Project Structure: Does it seem worthwhile to you to keep this front end project together with PANTS, and have me submit PR's when work is in a stable state? or would you prefer that the front end is a separate project, no PR's and only a mention to your code?

Prototype in Firefox:

from priceandnutritiontrackingsystem.

Nice work on the prototype frontend - paging through and changing ingredients it's noticeably faster than the Django admin for me.

1. I hadn't thought about the auth much, just assuming the built in session authentication via the 'api-auth' point (or the other login forms) for now. There will need to be more flexible authentication added for things like native clients.

2. I hadn't thought about CORS either - the API will definitely need the headers to allow access. I'll merge the relevant parts from commit 3ae2d51

3. My plan is to use django-filter for searching/filtering - this should also allow clients to search across multiple criteria, like "tagged with 'grain' and more than 10% fibre" and similar more complex queries.

4. I'll get the tags on the API soon so this can be tested properly.

5. Either way is fine by me, whichever you're most comfortable with. I'm often unwell and away for days or weeks, so keeping the projects separate would prevent that from holding up PRs or other development.

from priceandnutritiontrackingsystem.

Thank you for the clarifications. My apologies for my slow response - I was finishing up my undergrad this week.

1. Understood, the prototype is throwaway code so I will continue to use basic auth for now until I can understand how to log in from a separate front end.
2. I'll separate out my code for you and make a PR.
3. ✅
4. ✅
5. I'm a fan of combining efforts until there is a clear need to separate. I'll keep up with working in this project and making PRs.

from priceandnutritiontrackingsystem.