mcab / hiber Goto Github PK
View Code? Open in Web Editor NEWAPI for Bat House SDP
License: GNU General Public License v3.0
API for Bat House SDP
License: GNU General Public License v3.0
Right now, we have an assumption that the data / questions presented on the front-end will be relatively static.
But, it's possible that we would want to tweak questions, and the possible choices associated with such. The problem is, we would need to figure out how to dynamically resolve CHOICES
and the respective field it should go into the HouseInformation
table.
It's probably possible to version this based off of last updated, along with a slug to denote different versions, with an API to expose the most "recent" version.
On a high level, it looks like
api/
survey/
environment/
bat-house/
bat-presence/
Then, we can simply have the front-end:
We gain the flexibility of modifying the questions at the downside of added complexity of the correct data field and choices linked properly.
Alternatively, we store JSON blobs and then somehow find a way to serialize them in the administrative interface and CSV that is exported.
Fixtures are very helpful to create test data that is loaded every time when you wish to reset the database.
Since we now have APIs, testing APIs would be easier with fixtures, to make sure that certain users cannot see certain data.
In case of errors, instead of logging to a file, we should integrate some sort of error tracking to catch the errors and report it someplace.
Sentry comes to mind.
Turns out, DRF tokens don't scale too well.
Looking for a better solution.
Instead of having observations made on each bat house stored within the House model, we will split them off to another model. This allows us to easily retrieve from the API just the observations for a certain house.
Sprint 3 should have a UML diagram for it. But, not all fields are there. At minimum, we should keep track of when the observation was made (created).
Right now, Wagtail comes with group permissions, to give users the access to certain pages. We would like to figure out a way for Sponsors to have access to certain admin pages (#9) but not all of them (user data).
Must investigate to see what's possible.
Related to #3.
We need a way to store information about bat houses to users. For right now, storing information about houses would be a good place to start. The UML diagram in Sprint 3 should indicate what should be stored.
After #33 is put into place, we can set up a testing database to run our queries against to make sure that our API is tested properly.
The main premise behind this interface is that the survey questions asked can be collated into a CSV, along with the responses.
Each house should have a set of environment/physical questions, with their date too, grouped together in some form for later processing.
Currently, it does a relative path to the bat_image
due to using ImageRenditionField
. We can still use it, we just need to get the proper representation for the image using a HyperlinkedIdentityField (https://stackoverflow.com/questions/49527543/hyperlinkedidentityfield-requires-the-request-in-the-serializer-context)
We have data currently working, but currently, it only checks if the user is authenticated. If so, it will show all the data for that endpoint.
This cannot be shown during MVP.
Instead of storing all of the information given by the API in the House model, we can instead store it in a separate model. Since this should be a one-to-one relationship expressed by a foreign key, the House model should be put in first.
This should be in the Sprint 3 UML diagram.
This should be a part of the bat house itself, and not a part of the physical features.
This requires some destruction of migrations, moving a variable, and making sure that it performs a-okay.
Since Wagtail utilizes Django, we need a way to register and authenticate over API (so they can access only their bat houses, for example).
This might be trickier than expected.
Instead of using drf-extra-fields, use django-rest-framework-gis.
This will come after #22 is implemented, because we only use Range for those. However, Range is finicky with how numbers are bounded, so once we don't use it, then we can use a package that has GIS specific serializers.
Relies on #3 being done.
Once all of the models are created, we need to be able to pull this information through a publicly accessible API. Docs point us to "Adding custom page fields" to achieve this.
Should be able to test this with an API client (at /api/v2/*) and show that it responds in kind. Tests would work well, here!
https://docs.djangoproject.com/en/2.1/ref/contrib/gis/
Allows us to add location data to House
s. Requires PostGIS to be setup to an existing PostgreSQL database.
Right now, it shows an Items Enum for fields that we specified are ArrayFields.
Ideally, we have a way to pass in either the Enum version, or the human-readable version when passing a request, while rendering that out to the API in the correct manner.
Documentation might point us in the right direction, but it expects an array.
We'll use Wagtail as our administrative CMS + API for the "back-end" portion of our services.
Now that we have House, HouseInformation (HouseEnvironmentFeatures + HousePhysicalFeatures), and Observation all put in, plus a way to register over API, we need to now implement CRUD for those models. They always needed to be scoped to an authenticated user, and with the system in place, we can now test that.
Once this is in place, the view logic just needs to be made into JSON so that we can expose it for Flightplan, while the administrative side can just pull on the newest records for visualization and record keeping.
Instead of serializing the entire model on any particular view, we can have the default GET request for all resources and the default GET request for a specific instance (PK) have different views, to not have to retrieve / send a lot of data over the API.
In order to leave a few breadcrumbs / thoughts behind design choices, we should include documentation to indicate a lot of the thought process behind why things were done.
Probably in a folder like docs/
that's compiled besides other documentation on API usage.
We want to add some additional fields to keep track of, tied to each user.
When using *RangeField
in specific PostgreSQL fields, the bounds are always defined as [) (inclusive first number, exclusive last number). This can be changed in the database, but Django does not support changing those bounds.
So, when users enter in data in the administration panel, erroneous behavior can occur.
Say for example, a bat only has one pup per year. That would be entered in as 1 - 1 in the Wagtail interface. Stored in the database, that's [1, 1), which is an invalid range, and defaults to null
for the value. This shouldn't be the case.
One solution would be to break it up into two separate fields (min/max_(size|pups)), and create a serializer that ties the two fields for the API, like
"pups": {
"min": 1
"max": 1
}
We need a representation of the data we want to store in our database. This is where model creation comes in. It allows us to give attributes to models, so that we can have a consistent way to store and get data.
Related to #3.
There's actually a desire to tags which bats have been seen in a bat house. However, the old site did not have a way to have this tracked server side, while providing the information client side.
There is no current UML diagram for this, so reference the UI mockups to see what data might need to be stored. It's possible that certain characteristics (size, amount of pups) can be treated as strings, or even just a text body (based on how it's displayed in app.)
Since we want to get the environment/physical features when we access a specific instance of a house (/api/v1/house/PK/
), we need to serialize a subset of features for it.
Might be related to #35.
Right now, there's a default set of information pulled into the admin CMS (Pages, Images, Documents). We would like to be able to pull in information from the bat houses (House, HouseInformation, Observations, Bat) and display it in such a way.
This might be a bigger undertaking than expected.
Currently, trying to access any view underneath the API (so /api/bat) redirects to the documents. That should not happen.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.