In this course, you will develop more advanced web application programming skills. You will learn how to control data read and write access using methods, publish and subscribe. You will learn how to access your database and server shells using command line tools. You will use the SimpleSchema system to validate data and generate input forms automatically. You will see a complete collaborative code editing environment, TextCircle, being built from scratch. At the end of this course, you will be able to: - use Meteor methods to control data write access - use publish and subscribe to control data read access - install and use advanced Meteor packages - add user accounts to your applications - implement complex MongoDB filters - use the MongoDB and meteor server shells - define data validations schemas using SimpleSchema - generate data input forms automatically using SimpleSchema In this course, you will complete: 2 programming assignments taking ~4 hours each to complete 4 quizzes, each taking ~20 minutes to complete multiple practice quizzes, each taking ~5 minutes to complete Participation in or completion of this online course will not confer academic credit for University of London programmes
MongoDB shell
Loading...
Do curso por University of London
Web Application Development with JavaScript and MongoDB
479 classificações
University of London
479 classificações
Curso 4 de 6 em Specialization Responsive Website Development and Design
Na lição
User accounts, packages and methods
Welcome to the second module of 'Web Application Development with JavaScript and MongoDB!' In this module we will learn how to use the core user accounts packages, customise the user accounts UI using third party packages and search for and add packages to an application. We will also look at how to query MongoDB collections from the command line and learn how to control data write access using methods. Enjoy!
Conheça os instrutores
Dr Matthew Yee-KingLecturer
Computing Department, Goldsmiths, University of London
[MUSIC]
We're now going to take a little aside and find out how we can actually look
at the underlying database, which meteor is working with in our applications.
So far, it's kinda been hidden from view.
It's just this mysterious thing that we can dump things into and
pull things out of, but there's actually quite a lot going on in there,
which it's really interesting to have a poke around and see what's happening.
So first of all, let's find out what underlies the user accounts and
the way we do it is with the mongo shell.
So if you're, let's just check if your app is running.
So if you run meteor, looks like it's already running.
So to access the mongo shell, we type meteor mongo and
that logs in to the local database server.
So the default database server in meteor is mongo and
when we first installed meteor, it actually installed the mongo server for
us as well as the meteor layers on top of that.
And indeed, the Node.js system.
So there's a whole bunch of components inside that meteor framework,
which is getting stored automatically.
We don't need to worry about, but we're sort of now gonna unveil one of those,
which is the database server.
And mongo is a standard database server, which is of the category kind of no SQL.
So we might call it, we recorded a NoSQL database.
There are other types of databases and some of them you can use with meteor.
For example, the SQL database is MySQL and PostgreSQL.
The difference between these and the mongo has to do with how you store your data.
So mongo is quite open-minded about how you kind of store your data,
you don't have to specify schema beforehand, like table structures.
You just chuck stuff in there and kind of get on with it and
that's really a nice way of working with data for certain applications.
So let's just see what's in there, anyway.
So we're logged into mongo and
what we can do is ask it, which collections it has?
Now collections may be familiar if you remember that in our JavaScript code,
we defined a collection called documents.
And when we created it, we actually specified a string containing the word
documents and that's what the mongo collection is actually going to be called.
And indeed, there we have one collection called Mongo.
So we can do db, which refers to the database and
the name of the collection, which is documents and
findOne, which will pull out a document.
There it is.
And actually, there is only one document in there.
So if I do find() count(), you see it gives me a count of one.
So that's because everybody works on the same document,
because we've only got a single document in our collaborative document editor.
How about users?
But you see there's also another collection in there called users.
The reason I'm getting confused between the word collection and table is,
in more traditional databases like MySQL and PostgreSQL, we talk about tables.
In Mongo, we talk about collections.
So there's a user's collection there,
so db.users.findOne.
There's a user account and
let's just see how many there are.
There's one and if I was to go back to my application and
actually create a new user account, you will see and
that test call it test2@test.com, testtest.
There's now two accounts sitting there in the thing and
we can look at both of them by calling find and telling it to prettify it.
If we don't prettify it, it just looks like this.
Just a kind of flat dataset, but pretty kind of puts some formatting in there, so
it's a bit easier to read.
So what does a user account look like?
Well, here is one here.
So we've got an id, which is one of these ids that we've seen
before created at, when was that user account created.
Then their password, which is encrypted.
So, I think I typed in testtest and
you can see that turns into a load of gibberish there.
So it's a good idea to encrypt your passwords in your database in case anyone
gives hold of the contents of your database and
then they'll just have all the passwords, as well.
So, encrypting them makes it a little bit harder for
people to then access the passwords in plain text.
So that's that and then we can also see if there's any other collections.
I'm just noting that the user's collection was created by the package.
So when we install the package and start it up,
the user's account package does a bunch of clever stuff and
creates the user's collection and then automatically puts things into it and
manages that for us all sort of easily done with that plugin,
then we've got some more stuff in the docs and ops I'm interested in.
So if I do db.ops.find().count(), let's see how many are in there.
Oh, 40.
Now it says, 40 things in ops.
What do they look like?
FindOne and you'll see that an op relates
to a document, which is interesting.
So if I do db.documents.findOne()._ id,
you'll see actually it's the same id as the only document in the database.
So this operation pertains to that document and let's see.
If I was to, let's run that command 40.
If I then start editing the document,
here is my some new text.
You see that created 67 new entries in the ops table collection.
That means whenever I'm making edits, things are being dropped into ops and
ops is part of the shared JS library and it's a built-in thing that every
time you make an edit, it automatically propagates into the ops table.
And the reason we can't just, you might think,
why do we need to store all of these edits?
Well, the thing is imagine someone's making all their edits on a mobile
device or a device with a poor connection and they build up all these edits and
they're happily coding and then none of it is getting through to the central server.
And then somebody else is busy hacking away and then you end up with sort of two
different versions of the document, because they're not instantly propagating
and this is, you can imagine that this would be quite common with lots of people.
And suddenly, they get their connection back and all the edits go blurting into
the database and we need to somehow make sure that everybody then has the same
the most up-to-date document and so this is the kind of magic that I've shared JS.
So it has an algorithm, which can collects all of the edits that everybody's made and
then somehow figure out what to show everybody, so that it makes sense.
So let's say someone's made a bunch of edits to a bit of text,
which they've then deleted, but
then the current editing it before the delete happens, that could be a problem.
So the ops table is keeping track of it, and there's an algorithm, which share JS
has, which works on that and turns it into a meaningful document for everybody.
So that's just a quick aside where we've looked at the mongo share and
found out how we can look a the underlying database and
the collections that are being created by these different packages that we install.
So yeah, just go in there, have a poke around and see what you can find.
[MUSIC]
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
