-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Databases #17
Comments
Agree that levelup is very cool and also level in general makes sense as a first db. I think leveldb's modularity is the strongest argument for it, but there are other reasons as well. For example, being able to Also, it would be remiss of me not to mention dat |
Maybe we could have 2 weeks of databases? 1 week with levelDB as an entry-level DB (I haven't used it much myself but @nelsonic will have some experience to share I'm sure) and then another to explore others like redis and elasticsearch? |
@iteles I think 2 weeks of databases makes a lot of sense. Using the second week for something like redis or elasticsearch (haven't used it, but hear good things from you guys) could be cool. Equally, sticking with level and going deeper in any of the many directions level opens up could be cool (keyspace design, various cool dbs built on top of level, building a cool db on top of level ...) |
Only saw this now. [#TooManyNotifications] I'm still a huge fan of _RethinkDB_ which has the benefit of structured queries and _real-time_ updates over websockets, however, I'm not "pushing" it on the FAC students because its not available for "free" on any service (e.g: to try it on a demo app on Heroku...) To your question of whether people should learn LevelDB and LevelUp, it depends. As for ElasticSearch it serves a very specific purpose and for that purpose it's the best-in-class. _IMO_ these should be the _FAC Four_:
And then we should tell people to find one other DB over the weekend and present its' use-case, pros & cons to the rest of the cohort. Thoughts? |
I agree with @iteles on two weeks for databases. The problem I have with the idea of a _FAC Four_ is that I don't think we have enough time to cover them all adequately. If we are going to offer a general introduction to Data (and I agree wholeheartedly with @nelsonic on this one) then I am not sure we have enough time for even two databases. Let me suggest a _FAC One_. So, if we were going to introduce just one database, which one would it be? |
(@rjmk "The high level goal of the dat project is to build a streaming interface between every database and file storage backend in the world." This looks fantastic.) |
I'd forgotten about the irritating ephemeral file system on Heroku. I think that's what stopped @rub1e level evangelism during FAC 5. 'Introduction to Data' 👍. I would suggest that it is interleaved with the course though. A small amount before using databases, and more after, looking at it from different angles and with different levels of knowledge in the classroom. Given what people in the space know best, sticking with redis might make sense. MEAN is still a popular stack as far as I can tell, but seeing as we don't use express or angular, that doesn't say much about us using Mongo. I think it would be more forgiving than SQL while having some of the same flavour with writing queries. Postgres has the advantage that SQL is used everywhere. And data normalisation is cool. There could be a lot to learn / teach in terms of data with postgres as a starting point. Overall, I think redis, but it's not an opinion I hold particularly strongly |
I cannot help noticing that some of the FAC6 project teams are now using Firebase and, of course, they are loving it--because it is so easy. There are competing priorities here: what's a good foundation for students' understanding of a topic vs what's going to be expedient for their projects vs what skills are likely to be useful on dwyl projects. |
We used Firebase for our Boat Launch project and it was fairly easy to use. It's hosted online so you don't need to run a db server, you can access it from the front end if you wish with just a script tag and a callback function. It's similar to Redis in that it uses key value pairs, this requires some thought into how you want to structure your data as every Hash requires a unique key (could use time stamp). Theodashboard or GUI is really simple you can edit import (JSON format) and export data fairly readily. One thing I did notice was if you had a large data set I couldn't see how you could search/ query easily from the GUI. There are some cool features like GeoFire which allows you to access snapshots of the database via sockets for real time updates and plot co-ordinates onto a map. |
TeamMunch are currently using Redis. We went for it as it's super easy with node and that it's fast & flexible. I'd say that if you were going to do a FAC _One_, as discussed above, I would recommend Redis as the one to go for (even though I really enjoyed using Firebase). Most teams would likely be using it in their MVPs so equipping them with the appropriate knowledge seems to make sense. |
I agree with @hrdavies. Firebase is incredibly easy but perhaps too easy and it was definitely good and useful to learn how to use Redis first (and to incorporate it with Sockets). We decided to use Firebase for Skipit because the client wants to be able to see all of the user data on a dashboard. It's really cool because it’s so user friendly and is real-time but it's only free for upto 100 connections at once so maybe not great for bigger apps (unless you have lots of dollah billz $$$$ to burn through). If you want more connections then it costs at least $49/month..
|
I know we didn't spend a lot of time with LevelDB on FAC6, but has anyone who has had a chance to play with it got any views on whether it might be a good introduction to databases in Node?
It's not so much the LevelDB database itself that interests me as the LevelUp wrapper for Node and the various level bindings. It looks like LevelUp could be a great learning route into databases in general without us forcing people down a particular database route (other than one or other key-value store).
See e.g.https://youtu.be/C-SbXvXi7Og
@nelsonic? @rjmk?
The text was updated successfully, but these errors were encountered: