This part of my work has been challenging. The React app itself is working well now. It’s able to have a user interact with it to see the queries, modify the values in the fields, and run the customized query. But up until now, we’ve just been having it read these “presets” (from which all customized queries are derived) from hard code in the Get API. There were no CRUD operations configured for the customized queries. I’m working on implementing that now. The user not only needs to be able to run queries with customized fields, but also save them. This is why I need to spend time developing this.
We made a mistake in planning about a week ago, where we wanted to do everything related to queries in one GET route. They would read the queries by not including an id query string parameter and not including a save parameter. If they included an id query string parameter, it became a “read one”. If they included both the id and save query string parameter, it became an “update” in terms of CRUD operations. This seemed okay at the time (even though I recognized it broke RESTful conventions) because we didn’t realize how complicated it would get if we needed to update or create new customized queries.
Right now I’m refactoring the code to split it into multiple routes, some GET and some POST, all of which abide by RESTful conventions, meaning that a GET request does not modify state in the data store. Once this is done, the React app will need some re-adjusting to use these new routes for the functionality I already gave it (reading and running queries), and then I’ll have to add the rest of its needed functionality (updating queries and creating new ones, and perhaps deleting them too). This sounds like a lot of work, but I’m not feeling too bad about it, because my experience creating this part of our project has taught me a lot about planning APIs and I have a much clearer picture now about how things should fit together.