We are passing off a lot of information to our search function now back over inside of our local API
project, because local API, I'm inside my next's file.
We're going to start to do some refactoring inside of here and of course, actually start out some kind
of express server and start listening for traffic on given port saving and patching cells from the given
file.
The first thing I want to do here is really clarify exactly what the goal of our local API is.
So quick diagram.
All right, so a lot of stuff going on in this diagram.
We'll go over it step by step.
You might recall that I mentioned that the local API has three primary jobs.
First off, the local API is can be ran on a user's machine when they use our daybook application.
When a user makes use of our daybook application, we are not going to be running up that entire development
server.
It is not running at all.
That development server takes a lot of resources.
It takes a long time to start up because we have to start up all the code transpiring, all the bundling,
all that kind of stuff and all that set up and start up.
Time is just wasted time in general.
So whenever a user is running the local API.
The first route that we're going to put together inside there is a route that's going to fetch all the
built production assets for our reactor application.
So, for example, if the user makes a request to just localhost at Port 40 or 50 or whatever or our
local API is running on, we're going to send them back the indexed HTML file from our reactor application.
That HTML file will load up inside the user's browser.
There will, of course, be a couple of script tags inside of there in the browser, will make some
additional requests to go and get those additional JavaScript files from our local API.
So essentially, for the purpose or job number one right here, we need to make sure that our local
API is serving all the production assets of our REACT application, not just the indexed HTML file.
I only put that in this diagram to keep the diagram nice and simple.
Then after that, the two other things that our API needs to do is allow a browser to make a request
to something like get on cells whenever a user makes a request like this, we're going to take a look
at all the cells inside of the file.
And remember, that is the name, the file that was provided to the CLI.
We're going to take all the cells of those that file and send them back over to the browser.
So in this case, would be something like an array of cell objects and remember, every cell has an
ID content and type not so type here, but it does exist.
And then finally, third purpose or third goal of our local API, a user in their browser should be
able to make a change to a cell.
Whenever they do, we want to take the updated list of cells, post them to something like cells.
And our local API is going to take that list of cells and store them into a file.
And that is the same file that was provided when user ran that book server command.
Again, those are the three primary goals of our local API.
So in order to put all this stuff together, the first thing we definitely need is express.
We're going to use Express, we're doing all of our different requests, handling and stuff like that.
So let's take a pause right here and stall expressed in the next video and then start to wire up an
express server in just a moment.