I've made some progress with the first prototype of our Get API's visual tool. We ended up having a bit of work to do to organize things. We originally planned on having the queries the tool needs stored on a server and sent via AJAX to the client-side React tool. Our reasoning was that the connection string for the MongoDB database should not reside in client side code. After speaking with our team lead, we came to the conclusion this wasn't a big concern, because the MongoDB login can be made read-only, and this tool is only for Engineering.com staff anyways. So that simplified our design somewhat. There would be no need to make an API just for the React app to query (via AJAX) to get its (MongoDB) queries.

As I began coding, I realized that we would indeed have to go back to the original plan of having an API serve the queries. The MongoDB driver and the Mongoose ODM that we need to use to perform these MongoDB queries needs to run on Node.js. It's all server side technology, not client side. So no matter what, this has to run on the server. So our final way this is organized is:


  1. Node.js server with a GET route that serves the query objects (which include info for React to display them, and an execution component for the server to actually run).
  2. The React app using the axios library to query this API via AJAX to get what it needs to display query choices to the user browsing it. The app's button onClick action is to use AJAX to tell the Node.js server to actually execute that chosen query.
  3. That same Node.js server then using Mongoose to query our MongoDB database hosted on AWS (Amazon Web Services), returning to results of that query to the React app to display to the user, fulfilling the last AJAX request mentioned above.

It might seem complicated at first, but this is actually a good separation of concerns in my opinion. It's flexible in that we can allow it to save and modify queries (since they can be persisted by the Get API Node.js server), and there is absolutely no way an unsafe query can be executed against our data store. The precious data stays safe. Nice.


The next steps for me over the next few days are to refine this (right now very ugly) prototype, and combined with production data we plan to collect asap, learn more about what kind of queries it will provide the Engineering.com staff.

Note: This was originally posted on the blog I used for my co-op term while at Seneca College (mswelke.wordpress.com) before being imported here.