Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

techcrunch.com

Post reply on HN
Print view View original

31–40 of 56 posts

Re: Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

#31

Post by sgress454 »

knappador wrote: post #27

How to know if you might be a customer: Did you make a mockup that needs a backend but have little backend coding experience and are sick of including a bunch of the same libraries? If yes, maybe. In short, they're integrating some commonly used API's and backend programs (Elastic Search etc) and putting a graphical programming model on top of it. Crappy backends are pretty easy to throw up on a VPS or Heroku these d…

It's true that when this has been tried in the past, there's always been a point where the "magic" ends--where there's some functionality that you need which isn't included. Treeline is different because you can always create new components when you need them. The Machine specification (http://node-machine.org) is open-source, and you can upload new machinepacks to NPM (Treeline imports them automatically), or create them from right within the app. So the magic never has to end :)

Or as PG put it, "You get to make your own blocks!"

Re: Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

#32

Post by mikermcneil »

practicalpants wrote: post #29

Yep, I have something vaguely similar to this which I've built over the years for my own projects, essentially generators for boilerplate for back end stuff, written with preferred libraries, coding styles, testing approaches, etc. From who I know, I think it's common for back end devs. Yet I've never really built 'a simple' app... It does always requires substantial time tweaking, customizing, and building things th…

After building one of the largest backend frameworks for Node.js I completely understand where you're coming from. It's taken us a very long time to solve this problem, and I can say with complete intellectual honesty that I believe we've solved it. Check out http://michaelmcneil.com/post/112978579967/mikermcneil-outco... for a more technical explanation of how the compiler works.

Re: Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

#33

Post by fillskills »

particlebanana wrote: post #3

co-founder here if anyone has any questions

Would love to see it integrated with a front end building platform like Webflow. I just built a quick site with Webflow, but because it lacks any integration with DB/Backend it was only used as a landing page. Having this ability would let users create and end to end web product with only basic knowledge of programming.

Re: Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

#34

Post by mbesto »

mikermcneil wrote: post #25
salimmadjd wrote: post #24

This looks very very cool. But, who is the target audience here? IMHO, this doesn't have the best Product/Market fit. I'm guessing the target is a non-programmer or just front-end guy who quickly wants to put together a backend. If that's the target, then why not provide a set of generic backend functions. For the mentioned target. I think you can limited to a simple set like: registration, authentication, user profi…

Great question! Open source drag and drop functionality currently exists for things like sending emails (via mailgun or mandrill) payments (via stripe) sending SMS (via Twilio) social auth (via twitter, Facebook, or github) password encryption (via bcrypt) analytics (via segment.com) and over 100 other common functions

But who is the target audience?

Re: Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

#35

Post by salimmadjd »

capex wrote: post #26
salimmadjd wrote: post #24

This looks very very cool. But, who is the target audience here? IMHO, this doesn't have the best Product/Market fit. I'm guessing the target is a non-programmer or just front-end guy who quickly wants to put together a backend. If that's the target, then why not provide a set of generic backend functions. For the mentioned target. I think you can limited to a simple set like: registration, authentication, user profi…

There's [0]hull.io, doing a lot of the things you've mentioned here. [0] http://hull.io

Another person suggested, http://stamplay.com/

Re: Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

#36

Post by knappador »

sgress454 wrote: post #31
knappador wrote: post #27

How to know if you might be a customer: Did you make a mockup that needs a backend but have little backend coding experience and are sick of including a bunch of the same libraries? If yes, maybe. In short, they're integrating some commonly used API's and backend programs (Elastic Search etc) and putting a graphical programming model on top of it. Crappy backends are pretty easy to throw up on a VPS or Heroku these d…

It's true that when this has been tried in the past, there's always been a point where the "magic" ends--where there's some functionality that you need which isn't included. Treeline is different because you can always create new components when you need them. The Machine specification ( http://node-machine.org ) is open-source, and you can upload new machinepacks to NPM (Treeline imports them automatically), or crea…

I'd bump that point and the integration with API's way up in the site copy. My first thought as an engineer when I see graphical programming tools is, "oooh...another one of those." It's the most controversial selling point. If I know I can do 90% of my backend work fast enough to slap an MVP together, the tradeoff might make sense. My default plan is a VPS with Flask or some other cheapo web app server that can pull 300req/s. That's a step beyond just using Heroku, but also a valid competitive option.

How would you position your product relative to Heroku in terms of power and how much schlep you trade for how much ease-of-use? I think it's very okay to be clear for now in order to convert well with your core customers.

Re: Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

#37

Post by onion2k »

findjashua wrote: post #12
sgress454 wrote: post #10

Earlier quoted context omitted.

We're essentially in agreement--backend development should be the easy part, but it often ends up being needlessly complicated and broken. So many backend systems are made up of the same basic components, but they end up being rewritten all the time because they don't work well together or are poorly documented. Treeline aims to make that 80% of your app that's always the same and basically automate it for you, leavi…

I laud the effort of making it easier to build apps, but in my experience the backend stuff is mostly building the rest api and cron jobs, which are relatively straightforward. Imho, bulk of the complexity is in user interfaces with lots of moving parts.

It's trivial if your app is just CRUD with domain specific fields, but there can still be some tricky parts;

* Sync'ing data between the frontend and backend if your app has any sort of offline capabilities. Conflict resolution is hard if you want anything better than just a dumb overwrite of what's there.

* Data munging for anything that isn't coming from a well defined API is a horrible and difficult task.

* Scaling and replication on a global scale is still a challenge. It doesn't affect many apps though.

You can knock up a decent REST API in Laravel/Express/Django/whatever in a few hours, but getting the data that you push through it still represents some fun and challenging aspects of app development.

Re: Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

#38

Post by findjashua »

onion2k wrote: post #37
findjashua wrote: post #12

Earlier quoted context omitted.

I laud the effort of making it easier to build apps, but in my experience the backend stuff is mostly building the rest api and cron jobs, which are relatively straightforward. Imho, bulk of the complexity is in user interfaces with lots of moving parts.

It's trivial if your app is just CRUD with domain specific fields, but there can still be some tricky parts; * Sync'ing data between the frontend and backend if your app has any sort of offline capabilities. Conflict resolution is hard if you want anything better than just a dumb overwrite of what's there. * Data munging for anything that isn't coming from a well defined API is a horrible and difficult task. * Scalin…

Agree, those are all challenging problems to solve, but I haven't had the chance to work on them

1. we don't support offline mode in our app. Though, quite a few databases have a version number in their documents (es, couch etc), so the user can be shown conflicts if the server responds with a version mismatch

2. Luckily, I haven't had to work with any overly terrible APIs. The documentation is usually bad, but fiddling around with the req params/body usually gets me what I want

3. We're selling to businesses, so our traffic isn't at that scale.

Re: Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

#39

Post by sgress454 »

knappador wrote: post #36
sgress454 wrote: post #31

Earlier quoted context omitted.

It's true that when this has been tried in the past, there's always been a point where the "magic" ends--where there's some functionality that you need which isn't included. Treeline is different because you can always create new components when you need them. The Machine specification ( http://node-machine.org ) is open-source, and you can upload new machinepacks to NPM (Treeline imports them automatically), or crea…

I'd bump that point and the integration with API's way up in the site copy. My first thought as an engineer when I see graphical programming tools is, "oooh...another one of those." It's the most controversial selling point. If I know I can do 90% of my backend work fast enough to slap an MVP together, the tradeoff might make sense. My default plan is a VPS with Flask or some other cheapo web app server that can pull…

We're not a production hosting platform--at least not at the moment. We do spin up a preview server for you to play around with your app while you build it in Treeline, but it's not meant to compete with Heroku or any such provider. Instead, we give you a way to download your project as a fully-formed SailsJS app which you can deploy anywhere that supports Node. You can also use the same tool to preview your app on your local computer while still keeping it synched up with Treeline in real time--hooray for sockets!

Re: Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

#40

Post by knappador »

sgress454 wrote: post #39
knappador wrote: post #36

Earlier quoted context omitted.

I'd bump that point and the integration with API's way up in the site copy. My first thought as an engineer when I see graphical programming tools is, "oooh...another one of those." It's the most controversial selling point. If I know I can do 90% of my backend work fast enough to slap an MVP together, the tradeoff might make sense. My default plan is a VPS with Flask or some other cheapo web app server that can pull…

We're not a production hosting platform--at least not at the moment. We do spin up a preview server for you to play around with your app while you build it in Treeline, but it's not meant to compete with Heroku or any such provider. Instead, we give you a way to download your project as a fully-formed SailsJS app which you can deploy anywhere that supports Node. You can also use the same tool to preview your app on y…

Okay, cool. Now that I've finished being uninformed enough to get questions out of the way, I'm guessing you chose Sails because it has some kind of JS DB for prototyping. I would spend time asking if Sails is the desired output format because, although I've only used it during a Startup Weekend fling, it feels like a framework, and don't forget that it's said that while you can plug your code into a library, in Soviet framework, code plugs into you -- I imagine that although a backend dev might be thinking, "Great, Node, kill me softly with 'undefined'" they would still kill if the implementation was really minimal with nothing in their way; if they like another JS framework or want to write a common backend for web and mobile apps, not having Sails' distractions in the way could be big for legitimately doing some of their work for them.

Another big feature would be doing the work to plug persistence into other DB's to make the output DB agnostic to some extent. Migrations would be the next step, but too much of a chore. All you need are to define data models for XYZ ORM/DB adapter to make the machine-generated step hit the right starting point for hand-off. If the ideal use case is in prototyping, I don't think migrations is in the right vein.

Armchair-CTO, signing off.

Post reply on HN