[FoRK] outsourcing back end

Lucas Gonze lucas.gonze at gmail.com
Wed May 8 14:07:16 PDT 2013


Final result: I'm going with MeteorJS.

- Has molto funding, which makes support likely for the medium term

- More focused on ease of development than derbyjs

- Slightly ahead of derbyjs in twitter followers and google searches


On Wed, May 8, 2013 at 11:46 AM, Lucas Gonze <lucas.gonze at gmail.com> wrote:

> gojomo, you win the s/n prize. I didn't know derbyjs, deployd, or
> helios.io - thanks for the clue trail.
>
> The biggest problem I have is picking a framework that hits limits or gets
> orphaned. I wish the technology shakeout was farther along.
>
> When I say "static" I mean CSS, Javascript and HTML. You're constantly
> fiddling with that stuff so need the deployment and development tools on a
> full-service platform.
>
>
>
>
> On Wed, May 8, 2013 at 10:39 AM, Gordon Mohr <gojomo-forkxent at xavvy.com>wrote:
>
>> On 5/7/13 10:49 PM, Lucas Gonze wrote:
>>
>>> I'm working on a new browser app, and I'm considering an architecture
>>> with
>>> these axioms:
>>>
>>> - As much as possible on the client
>>> - Outsource backend infrastructure
>>>
>>> For example, Backbone on the front, static resources on Heroku, dynamic
>>> backend resources on Parse.com or Firebase.
>>>
>>> Comments welcome. Is this wise at this point, or should I wait a couple
>>> years for things to shake out?
>>>
>>
>> My impression, more from following broad trends than implementation
>> experience, is that what you describe is a good, ripe approach if it fits
>> your app.
>>
>> There's lots of frameworks and hosted services all dancing around the
>> same rich-client, generic-REST-backend architecture. In addition to the two
>> you mention (Parse.com and Firebase), see also:
>>
>> http://derbyjs.com/
>>
>> http://deployd.com/
>>
>> (Parse and other variants like http://helios.io/ add services that are
>> especially appropriate for native mobile-apps as well as rich-web apps.)
>>
>> And, REST drop-ins for other popular frameworks (Rails, Django, etc) mean
>> those are back-end options, as well.
>>
>> Sure, there's so much evolution happening you might pick one that hits
>> limits or gets orphaned, but for simple back-end needs they all have enough
>> of a family resemblance, occasional transitions (to get a new feature or
>> pick a better host) shouldn't be hard. So, no waiting for things to shake
>> out, just go and adapt if/when necessary.
>>
>> (Not sure why you highlight Heroku for 'static' stuff: while it works
>> they tend to discourage it, and nudge you towards using something like S3
>> for any bulk static serving.)
>>
>> - Gordon
>>
>> ______________________________**_________________
>> FoRK mailing list
>> http://xent.com/mailman/**listinfo/fork<http://xent.com/mailman/listinfo/fork>
>>
>
>


More information about the FoRK mailing list