search

koopjs / koop

Transform, query, and download geospatial data on the web.
http://koopjs.github.io
Other
675 stars 129 forks source link

Simplify Koop: remove Sails #64

Closed chelm closed 10 years ago

chelm commented 10 years ago

Koop isnt really using sails. This task is about making everything more simple and pluggable. It will become a simple extension of express and no functionality will change.

The config structure will be impacted but will be better for prod vs dev params.

mjuniper commented 10 years ago

:+1:

patrickarlt commented 10 years ago

We have started using HAPI with great success. So far I like it a lot more then express and it has a dedicated and smart team behind it https://github.com/spumko/hapi

chelm commented 10 years ago

@patrickarlt Cool! Yeah I think that's a great idea I've heard great things about HAPI. I think as long as I can start a server and dynamic attach routes->handlers then it should work. The goal is to be as simple and modular as possible.

In addition to this I wanted ping yourself and @JerrySievert about how I might leverage npm to install Koop Providers. I've been thinking a lot about it, and I'm looking to essentially say: 'npm install koop-provider-github' and then when the server starts up a boostrap script finds the install modules and loads them. I'll formally send you the question.

patrickarlt commented 10 years ago

HAPI is supposed to be really plugable. They have a plugin architechture and also a concept of "Packs" the group and launch multiple servers. I havn't played with any of it yet but It looks like its all there.

@ngoldman and I both read through https://medium.com/the-javascript-collection/d82777afaa4b which was really helpful and explains quite a bit.

patrickarlt commented 10 years ago

@chelm The way I think most people do automagically loading modules is to just regex package.json and look for all module matching a pattern and require them.

@JerrySievert might know a better way though.

chelm commented 10 years ago

@patrickarlt that makes sense. It seems like the most common way.

JerrySievert commented 10 years ago

the pattern i've seen is a try block for require and not using it if it fails. not sure if that's what we want to do in the short term?

also, HAPI is supported locally, we can lure in a developer with the premise of a towerfall game and lock him in :)

chelm commented 10 years ago

Just read that post on HAPI - love it. It fits really well. I'm going to refactor my feature service code (which is horrid right now) and then will create a HAPI branch.

Thanks @patrickarlt & @JerrySievert

chelm commented 10 years ago

Just wrapped up the first pass of a major refactor. I decided to not go with Hapi and am still using straight up Express. I had the pattern all fleshed out and am feeling good about what i've done. Basically the koop repo is extremely simple and relies of npm modules for loading in all providers. This way each provider can be developed and tested really cleanly on its own, in separate repos.