Now that we understand the very easy way of putting all the stuff together, we're going to take a look
at a much more complicated solution.
In this course, we're going to use the more complicated solution.
We're going to take a look at a few diagrams in this video and understand why we would ever want to
use this more complicated solution.
I'm not just going to come out and say right away, hey, here's what we're doing.
I first want you to understand why we might want to take a more complicated approach at all.
OK, so first, a very quick review of how we are really intending a user to use our application right
now.
So our goal is to allow a user to run something like Northparkes JDBC surf that is going to run some
locally installed module on the user's computer when that module runs.
So this is really our Seelie right here.
We want the Seelie to start up a local Express API.
This local Express API is going to modify some file.
Maybe it's called Notebook's, maybe it's called my notes.
Dot just doesn't really matter.
That is a file that's going to contain all the user's cells.
So the raw code, the raw text for them as well.
The Express API is also making our REACT application available inside the browser as well.
So this is pretty much where we kind of understand things to be right now.
But I want to imagine how a user might eventually want to use our application in the future with this
current setup that we are looking at, we're really just saying that a user can only ever make use of
our Facebook application on their local machine.
So what would happen if a user starts to write out a series of notes inside of one of their notebooks
with some really awesome notes inside of it, maybe that they write out a full tutorial on how to use
react or something like that, and they've got an awesome notebook that they want to share with the
rest of the world.
How would we allow a user to share this thing effectively?
We are currently writing all this cell data into this notebook file, or at least that's what we plan
on doing.
How would we allow a user to share that information with other people across the world without requiring
them to first install Gebek onto their local machine?
This is a big question I want to think about for just a moment.
How would we allow a user to share these notebooks?
Well, let's imagine for just a second that we want to expand our application in a very dramatic way,
maybe in addition to allowing a user to run locally on their machine, maybe we also have some kind
of public API as well, or a public diploid version of our JUMBUCK application.
So in other words, in order to share this notebook with other people across the world, maybe adding
an additional command to our books July, maybe something like Gebek publish, so user would be able
to run something like JDBC, publish and then a file that they want to publish.
We then might upload that file to some public API that you and I manage.
And then once we've uploaded that file, we could post that file and all the notes inside of it at some
static address like, say, JDBC, dotcom, some ID for that particular notebook.
A user could then take this URL right here, share with other users and say, hey, you go to this address
and take a look at this really awesome notebook I put together.
So I think that this would be absolutely awesome.
If we had something like this, this would really allow you and I to expand this application in dramatic
ways, we've now got a very easy way that users can share notebooks.
We can maybe allow users to make changes to other people's notebooks, stuff like that.
But if we want to implement something like this, that's really kind of implying that you and I are
going to put together some kind of public outside Express API or any kind of API, doesn't necessarily
have to be express.
You and I might host this at something like JDBC, dotcom or something like that.
Not to be clear, this is a completely separate server that you and I would manage.
It is running on some publicly hosted domain.
It is running on Google Cloud or RWC or something like that.
This API right here is completely separate from the local express API that is running on a user's machine.
This API right here, this is only about reading and writing sells to a single file and serving up the
react application.
This public API right here is going to do kind of all that same stuff.
It can serve up a list of cells save sells, it can serve up the react application.
But we might want to to have a lot of additional functionality as well.
For example, we might want to require a user to log in or sign up to our application before we ever
allow them to publish a notebook.
We might want to have some series of permissions or something like that that decides whether or not
a user is allowed to edit a notebook hosted at Gebo Dotcom or just other features such as that.
Now, to be clear, we are not going to add in this thing inside this course, this is just really an
example of some way that we might want to expand our application in the future.
Now that we've got an idea of this kind of additional piece of technology or this additional server
that we really need to add into our project, how would we really add this in?
Well, I think that we can start to consider all the different parts of our application that we've kind
of established that we need, we've got the Seelie, which needs to know how to start up the local API
so user can edit a notebook locally on their machine.
Seelie also needs to know how to publish a notebook to our public API.
So in other words, how to take the contents of some file like this thing right here and send it off
to our public API hosted at Baucom.
So the Seelie now really has a tie directly to the local Express API and to the Public Express API.
The local API needs to be able to serve the react application and save and load cells to and from a
file.
The public express API needs to be able to serve up to react up as well.
It needs to also save and load cells.
But in this case, we don't really have to save and load these cells to a file.
Instead, we can just save them inside of a database or something like that.
The whole file requirement that we've been talking about here is just to make it easier for users to
share these files or commit them to get in stuff like that.
But the Public Express API is also going to have some additional functionality that it requires, for
example, beyond the local Express API.
It might also need to handle authentication, permissions, some other stuff as well.
It might need some kind of marketing page.
So something to explain what all this stuff is and so on.
And then finally, the last part is our REACT application, the REACT application needs to make its
production assets available either to the local API so the user can run the reactor up on the machine.
But it might also need to make all of its production assets available to the public API as well.
So we can actually go to, say, Jay Bookham and see a notebook loaded up on the screen over there as
well.
So now, whereas before when we were saying just a moment ago that we could just add in a script to
our ReachOut project in the scene, like a very easy and simple way to handle everything, now it's
seeming like we really want to have these more distinct parts, these very different things.
And some of these different things have very similar shared functionality, such as the local and the
Express API.
Those both need to be able to serve up the REACT application and have some logic inside them about saving
and loading cells.
But they're also slightly different as well.
The local API is only ever going to run on a user's machine.
It doesn't need to know anything about authentication or anything like that.
In addition, the Seelie, whereas before it seemed like, well, yeah, we could just write out some
logic inside of the server command or something like that to just very simply start up a local node
API.
Now we're kind of saying that the cloud is going to have more functionality tied to it.
Not only needs to somehow start up a local API, but also is going to have some logic inside there to
understand how to take a notebook file and publish it off to an API as well.
So no longer does it necessarily make a lot of sense to almost embed this thing into the local Express
API.
It's really kind of its own standalone thing as well.
And then finally, the react application no longer does it really make sense to you embed, say, the
local Express API inside there doesn't really make any sense to try to embed the Seelie inside there
either, because, again, it's really its own single thing.
And we need to take those production assets from it and make them available to both versions of our
API.
So I think that at this point in time.
It doesn't really make a lot of sense to try to add in all these additional pieces of functionality
direct into our ReachOut project.
I don't think it would make a lot of sense.
You would just have, say, a serve command inside there anymore that tries to do all this stuff.
Instead, the reactive project is really just about the react application itself, some front end components,
stuff like that.
And I think it really doesn't make a lot of sense to try to write in a lot of logic inside there around,
say, starting up a local API or publishing any files around writing and reading from some file on the
local machine, or most especially around handling authentication or stuff like that, which we would
want to do in this public API.
So at this point in time, it really seems like we really would want to split each of these separate
parts of our project out into these standalone kind of separate entities, but still kind of have some
tenuous ties between them, because we still want this Seelie to be able to start up the local Express
API.
We still want this local Express API to access some of the assets created by our REACT application.
And we probably still want this Public Express API to read some of these react assets as well.
So again, they're kind, they're standalone things.
They're kind of all separate projects, but they still kind of depend upon each other just a little
bit.
All right, so at this point in time, I just want to say I know a lot of this stuff is a little bit
esoteric, a little bit kind of crazy and hard to understand.
All I'm trying to do right here is establish a case for making these different parts of our applications
into separate kind of standalone small projects, as opposed to trying to combine everything together
into one single project.
So that's all I really want you to understand at this point.
The other thing I want to just make sure is super crystal clear.
Once again, we are not going to be building this public express API thing.
This is just an example of how we might want to expand our application in the future.
It is incredibly possible that you might continue developing this book thing that we're building inside
this course and eventually say, you know what, this is an awesome developer tool.
I think that this could work as a company or a startup or something like that.
And so I'm just kind of imagining down the road, if you continue developing a playbook, I think you
might eventually want something like this.
So we're not building it.
But I think it's incredibly possible that if this was a real application we were building, you would
want to put something like this together at some point in time.
OK, so, again, at this point, all we need to understand, these are all separate things, they kind
of depend upon each other.
So that mind quick pause right here.
We're going to come back next video and take a look at a better way of architecting your application
and kind of taking this whole thing into account.