Closed Bug 871869 Opened 13 years ago Closed 13 years ago

Party (events) data model

Categories

(Webmaker Graveyard :: webmaker.org, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: daniel, Assigned: hike)

References

Details

(Whiteboard: s=2013w22)

Attachments

(1 file)

Hi, So we're working on implementing the party (events) section to webmaker.org. Since it involves some DB interaction I'd love to speed things up by using an ORM. Mike said we're using MySQL as the DB backend, and as a result I'd suggest the following: https://github.com/dresende/node-orm2 https://github.com/1602/compound Node-orm2 is a good choice if we want to keep things as the project is today (just using Express). It includes an express middleware to make this easy. But, I'd love to refactor things a bit and use compound. It provides a *lot* more functionality that would be very useful and make development all the faster. Since the project is a bit early, the time to do this is now, if we want to. Compound provides a great CLI, route definitions for RESTful resources (which parties are) that take up one line instead of 7, and a great project directory structure / conventions. It even has a REPL console which allows for debugging and manipulation of the database models in a live way. Check out the README on Compound's github for more information. Let me know what you guys decide. If we decide not to use Compound, and stick with a more bare-bones Express project, then we can use the node-orm2 to provide the DB interaction, and add whatever other libraries we need on top to get the rest done.
Blocks: 871877
Upon further investigation if we don't want to use Compound, I'd suggest Sequelize over node-orm2. I implemented node-orm2 as a test today and hit some issues with it. Sequelize is just more mature. http://www.sequelizejs.com/
We use sequelize in all of our other apps, so feel free to run with that. I truthfully know nothing about Compound. It sounds like it does a ton of stuff though, so maybe worth whipping up a prototype with it?
Assignee: nobody → daniel
Okay I went ahead and started using Sequelize. The following is my starting point, let me know if you have any feedback or comments before I get too much further along. I've basically implemented the show and index methods for parties via a JSON api (still needs a bit more error handling and checking): https://github.com/AmoebaConsulting/webmaker.org/compare/parties
Status: NEW → ASSIGNED
Flags: needinfo?
express-resource looks pretty cool, I haven't seen that before. The only comment I have is that making app a global var seems like a bad idea. If you just need access to the DB models, could you do something like pass in the DB models or require() them directly?
Flags: needinfo?
Jon, Yeah I thought someone might comment about that. I thought about it pretty hard. The reason I did it is that if you require() models more than once, it will create multiple DB connections. Thus, since we only want the models required once, I thought to set them into the app singleton and make that available globally. If you disagree with this approach we have a few options: a) Only make models globally available (i.e. require() them to GLOBAL.models) b) I could perhaps rewrite the models file so it follows a singleton pattern I have seen a few node.js projects expose the app singleton as a GLOBAL and don't think it's *that* bad of an idea. Curious if you have specific concerns or have seen any issue with this sort of pattern before?
Okay I went ahead and also did a quick implementation using Compound.js quickly to show it off. This will save us a lot of time imho, and is worth doing. But if there's a lot of resistance on other folks' part I understand and am willing to scrap it. Check out: https://github.com/AmoebaConsulting/webmaker.org-compound The README describes how to set up a dev environment. When you run the server you can access http://localhost:3000/parties and get an index view of parties, complete with form editors, etc. It also provides an API automatically since everything is RESTful. For instance: http://localhost:3000/parties.json will return the parties as a JSON array, and can be used for AJAXing stuff in. Right now the template language is ejs, but I could easily switch that if you prefer something else (such as jade) if you prefer. Most everything in compound is overrideable somehow. I see this as providing a lot of useful stuff: * Free RESTful APIs * Nice conventions / project structure * DB migrations (would have to build a system otherwise) * DB seeding (would have to build a system otherwise for testing locally w/ data) * A REPL console which makes debugging/development SO much easier * Deployable on Heroku/AWS/anything really easily * Model relationships done easily (Sequelize makes this a PITA at times) Feedback would be most appreciated from the community asap. I didn't go so far as to use CoffeeScript, since I thought that might start a war. But it supports that too :-P I'm going to move on to try and tackle some of the Google Maps API stuff now while I wait for feedback.
Flags: needinfo?
Attachment #749608 - Flags: feedback?(jon)
Flags: needinfo?
Note that this is just a proof of concept, and I generated the entire thing with two commands: compound init webmaker.org compound g scaffold party title description:text expectedCount:number location b egins:date ends:date externalLink organizer:number partner:number image hashtag createdAt:date compound db migrate The frontend is totally scaffolded and would be replaced with the templates / HTML that we design (right now it uses EJS and some twitter bootstrap stuff that could be pulled out). This should be looked at as a proof of concept, and a demonstration of the power that compound provides.
(In reply to Daniel Jabbour from comment #5) > I have seen a few node.js projects expose the app singleton as a GLOBAL and > don't think it's *that* bad of an idea. Curious if you have specific > concerns or have seen any issue with this sort of pattern before? I am generally uncomfortable with globals in nodejs, especially since a module system makes it so easy to just require() what you need. (In reply to Daniel Jabbour from comment #6) > Feedback would be most appreciated from the community asap. I didn't go so > far as to use CoffeeScript, since I thought that might start a war. But it > supports that too :-P Compound does seem pretty cool, it feels very much like Django in what it provides. I have two concerns about it though: 1) How much effort would it take to move the existing content in webmaker.org into compound? How long would patches in progress be blocked on doing this? 2) None of us are familiar with it. That's a worry that really won't go away until we've used it For these two reasons, I think the best plan here is that we use Compound but we build it out in a separate repo (events.webmaker.org?). That means you guys can run with Compound and build something quick without being blocked on us or vice versa. Plus, we'll all get familiar with Compound so we can evaluate if it's a framework that we want to use instead of plain Express for other apps. In terms of language preferences, we definitely want JavaScript over CoffeeScript. For a CSS preprocessor we use LESS in our other projects pretty consistently, so it'd probably be good to stick with that unless there are reasons to use Stylus. In terms of templating languages we've used Jade, EJS and Nunjucks before. My personal preference is: 1) Nunjucks (developed by a Mozillian, and basically a port of Jinja2) 2) EJS 3) Jade If there's a Nunjucks plugin for Compound then off to races we go! If not, EJS is fine too. Let me know if you need any other information! If you set the "Need more information from" checkbox, change the dropdown to say "Other" and then write my nickname ":jbuck" in the input box.
Attachment #749608 - Flags: feedback?(jon)
Assignee: daniel → hike
Okay, sounds good. We'll proceed with a compound.js app, but keep the events stuff separated out in that. We just need to figure out how it will integrate with the rest of the site. You can deploy it as a separate app/repo on events.webmaker.org (per your suggestion), or we could potentially look into putting it in a folder in your webmaker.org repo (so it'd be at webmaker.org/events), and wire it in somehow so requests to /events run through compound. For now we'll proceed with building out the CRUD and map api stuff (as we have), but let's think about how we can wire everything together to make it as clean as possible. We'll get back to you in a day or two with ideas. What's your IRC nick? Perhaps we could discuss it there.
Flags: needinfo?(jon)
I think for now we can get staging kit live at events.webmaker.org and look at tighter integration if it's necessary later. I'm :jbuck on IRC as well, so ping me during the day if you want to discuss anything at all!
Flags: needinfo?(jon)
Blocks: 871878
Whiteboard: s=2013w21
Will update this bug tomorrow based on demo at 4:00 Pacific
Whiteboard: s=2013w21 → s=2013w22
Here's the current Event data model (as defined in db/schema.js and app/models/event.js): title: String description: Text address: String latitude: Text longitude: Text attendees: Number // enum (0..5) beginDate: Date endDate: Date beginTime: Date endTime: Date registerLink: String // registration URL picture: Text // data-uri blob organizer: String // email address created: Date This is more or less stable right now, so I'm going to go ahead and close this ticket.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: