Ask HN: What's your favorite way of getting a web app up quickly in 2018?
568 comments
Vanilla php + html5up + sqlite3.
Everyone else here is trying to be stylish and fancy.
Your customers don't care what language it's in or whether the code is beautiful.
No cutting edge incomplete frameworks, convoluted tooling, piles of inaccurate documentation to read, inexplicable cryptic error messages with a bunch of incorrect solutions on stack overflow, or other incompetently over engineered bullshit.
Just go as vanilla, basic, and standard as possible.
True speed comes when you don't have to deal with other people's bugs and poorly designed mistakes.
Don't rely on code written by flocks of people you'd never hire in a million years.
Everyone else here is trying to be stylish and fancy.
Your customers don't care what language it's in or whether the code is beautiful.
No cutting edge incomplete frameworks, convoluted tooling, piles of inaccurate documentation to read, inexplicable cryptic error messages with a bunch of incorrect solutions on stack overflow, or other incompetently over engineered bullshit.
Just go as vanilla, basic, and standard as possible.
True speed comes when you don't have to deal with other people's bugs and poorly designed mistakes.
Don't rely on code written by flocks of people you'd never hire in a million years.
>No cutting edge incomplete frameworks
So what, you rewrite a templating engine every time you want to make an application that outputs user data? Or are you reliant on making damn sure you always call htmlentities every time you echo something to prevent XSS? Are you sure you've not slipped up anywhere?
What about CSRF? Do you write your own filtering mechanism every time you make a web app to check for the existence of a CSRF token in all state-altering (e.g. POST) requests?
There are reasons people use frameworks. Security is one of them - I _love_ assessing apps which are written in plain PHP because they're almost always a trainwreck. You don't tend to see SQLi from devs who tend to use ORMs, nor do normally you see stuff like LFI if they're using a well-known templating engine.
Can you write secure code in PHP? Absolutely. But it's more effort and easier to get wrong.
Your client may not care about the technical details, but when the security assessment report says your PHP app has a stored XSS and an equivalent ASP.NET MVC app is safe..
So what, you rewrite a templating engine every time you want to make an application that outputs user data? Or are you reliant on making damn sure you always call htmlentities every time you echo something to prevent XSS? Are you sure you've not slipped up anywhere?
What about CSRF? Do you write your own filtering mechanism every time you make a web app to check for the existence of a CSRF token in all state-altering (e.g. POST) requests?
There are reasons people use frameworks. Security is one of them - I _love_ assessing apps which are written in plain PHP because they're almost always a trainwreck. You don't tend to see SQLi from devs who tend to use ORMs, nor do normally you see stuff like LFI if they're using a well-known templating engine.
Can you write secure code in PHP? Absolutely. But it's more effort and easier to get wrong.
Your client may not care about the technical details, but when the security assessment report says your PHP app has a stored XSS and an equivalent ASP.NET MVC app is safe..
The other side of the coin is whether you do a full security audit of every framework and dependency graph before you use it? When you write your own code you know there is nothing hidden.
That's a highly simplistic and incorrect way of looking at it. Do you know what CSRF is? Do you want to implement it every time you create a website? And all the other XSS vulnerabilities that could occur because you weren't careful.
Frameworks are much better at handling most security needs.
Frameworks are much better at handling most security needs.
Most of the higher level code like that is written by incompetent people who make amateur hour mistakes and only release overengineered under documented slow broken code that is never supported and gets deprecated in a week.
I'm constantly shocked and amazed at the beginner mistakes riddled throughout these hip cool kid frameworks. And the dependencies of that code, and their dependencies, and the build system, and the management of the build system. It's a 5,000 hour a week job fixing all that and someone else will just go in and break it again.
So no, don't tell me to stop my life and fix everyone's mistakes. This is why there's 10 person teams to build an ecommerce site these days. This used to be a weekend project before all these slick stylish tools took up everyone's time.
Most people are incompetent and the more complexity you have, the greater your chances of getting crap code tearing your system apart
Why would I use something as a core piece of infrastructure written by people I'd never even consider hiring in a million years?
All too often you're standing on the shoulders of people tripping over their own shoelaces.
No thank you.
I'm constantly shocked and amazed at the beginner mistakes riddled throughout these hip cool kid frameworks. And the dependencies of that code, and their dependencies, and the build system, and the management of the build system. It's a 5,000 hour a week job fixing all that and someone else will just go in and break it again.
So no, don't tell me to stop my life and fix everyone's mistakes. This is why there's 10 person teams to build an ecommerce site these days. This used to be a weekend project before all these slick stylish tools took up everyone's time.
Most people are incompetent and the more complexity you have, the greater your chances of getting crap code tearing your system apart
Why would I use something as a core piece of infrastructure written by people I'd never even consider hiring in a million years?
All too often you're standing on the shoulders of people tripping over their own shoelaces.
No thank you.
>>There are reasons people use frameworks. Security is one of them - I _love_ assessing apps which are written in plain PHP because they're almost always a trainwreck.
It’s totally OK for a prototype to be a trainwreck because its purpose is to give you the ability to launch it in front of potential users, show them a few features and get their feedback.
It’s totally OK for a prototype to be a trainwreck because its purpose is to give you the ability to launch it in front of potential users, show them a few features and get their feedback.
If it is open to the public, your train wreck cannot be open to common vulnerabilities like sql injection. Full stop. You can avoid unit or integration tests, not complete features, or cut any corner you want aside from basic security.
Don't presume anyone writing PHP is a trainwreck. With PHP7+ you can write modern applications that are perfectly secure, as much as anything you'd write with any other scripting language.
> Don't presume anyone writing PHP is a trainwreck.
I'm unsure anyone here is disputing this - my original comment said as much:
> Can you write secure code in PHP? Absolutely. But it's more effort and easier to get wrong.
It's undeniably more work to get right, though. As an example, if I create a new django app "the CSRF middleware is activated by default in the MIDDLEWARE setting" - you're safe by default.
I mean, even as a basic DiD measure PHP could use SameSite cookies by default for its sessions - but does it?
I'm unsure anyone here is disputing this - my original comment said as much:
> Can you write secure code in PHP? Absolutely. But it's more effort and easier to get wrong.
It's undeniably more work to get right, though. As an example, if I create a new django app "the CSRF middleware is activated by default in the MIDDLEWARE setting" - you're safe by default.
I mean, even as a basic DiD measure PHP could use SameSite cookies by default for its sessions - but does it?
Sure it can. Almost every website on the internet right now has undiscovered security holes. Obviously you won't be leaving them open on purpose, but not using a framework is a legit choice and "it provides security that you can't implement without one" is a bad argument.
Yes there's convenience in "somebody already thought about everything you need before you did" but there are also security libraries, checklists, tutorials, and other tools besides a full framework with all its baggage to help developers write secure code.
Yes there's convenience in "somebody already thought about everything you need before you did" but there are also security libraries, checklists, tutorials, and other tools besides a full framework with all its baggage to help developers write secure code.
I'm not saying anything either way on frameworks. But SQL injection is into to web development stuff. You can worry about cross site scripting or other security stuff later for a PoC,but not SQL injection.
[deleted]
This comment is highly presumptuous about the actual development experience of more modern languages and tools.
> True speed comes when you don't have to deal with other people's bugs and poorly designed mistakes.
PHP is often, in practice, a language where bugs are more likely compared to these "stylish" other languages you mention. [0]
[0] http://delivery.acm.org/10.1145/3130000/3126905/p91-ray.pdf?...
" For [languages] with positive coefficients we can expect that the language is associated with a greater number of defect fixes. These languages include C, C++, Objective-C, Php, and Python. The languages Clojure, Haskell, Ruby, and Scala, all have negative coefficients implying that these languages are less likely than average to result in defect fixing commits."
> True speed comes when you don't have to deal with other people's bugs and poorly designed mistakes.
PHP is often, in practice, a language where bugs are more likely compared to these "stylish" other languages you mention. [0]
[0] http://delivery.acm.org/10.1145/3130000/3126905/p91-ray.pdf?...
" For [languages] with positive coefficients we can expect that the language is associated with a greater number of defect fixes. These languages include C, C++, Objective-C, Php, and Python. The languages Clojure, Haskell, Ruby, and Scala, all have negative coefficients implying that these languages are less likely than average to result in defect fixing commits."
It's too late for me to edit my comment, but here is the proper link:
http://dx.doi.org/10.1145/3126905
http://dx.doi.org/10.1145/3126905
I wonder why Ruby ended up in the negative coefficient group instead of exhibiting similar characteristics to Python, for example.
It's quite an interesting study to read, and not long. I recommend giving it a few minutes to answer that question.
Thanks, assumed it would be too academic or technical to understand and didn’t look at it. Will check now..
Actually, the link is not working on mobile. Maybe it will work on my desktop.
Actually, the link is not working on mobile. Maybe it will work on my desktop.
Try this permalink instead: http://dx.doi.org/10.1145/3126905
I wish they included Haskell in the concurrency bugs section, given how popular Software Transactional Memory – which eliminates many concurrency bugs – is there.
Thank you. I've never come across html5up [1] before, but the templates there are just what I'm after at the moment.
1. https://html5up.net/
1. https://html5up.net/
I don't get it. They all look practically the same, just with different color schemes and splash backgrounds?
Agreed, this is a great resource. Is there anything else like this out there?
You seem to know a lot about what everyone else's motives are :)
There's nothing less "vanilla" or "standard" with python/go/RoR/whatever vs. PHP. It just so happens that you know PHP well, so, by all means, YOU should use that.
There's nothing less "vanilla" or "standard" with python/go/RoR/whatever vs. PHP. It just so happens that you know PHP well, so, by all means, YOU should use that.
One can put together a set of (Fast)CGI scripts in almost any language, given environment variables and some IPC is supported (IDK what IPC FastCGI uses exactly, bug CGI is envvars). Same goes with exposing a custom socket server. I guess people associate languages with frameworks and that's why they think these things are not possible in them. Or they like the <?php ?> style intermingling of 4 programming languages, which is a pathetic bad practice that turns the program into a pseudo-quine immediately. Just read the source of a WordPress plugin (keep a nylon bag handy because it's gonna give you nausea, to say the least).
As someone in a position who's primary job has [had] little to do with WordPress plugin work, but is at the same time increasingly exposed to that due to sales department directives...
you've understated it.
And while I'm not a huge fan of working in PHP, it has its place— my remark is unrelated to that.
you've understated it.
And while I'm not a huge fan of working in PHP, it has its place— my remark is unrelated to that.
Except OP made no mention of Wordpress, its notoriously bad and any decent developer who also happens to use PHP knows not to touch it with a ten foot pole.
You're wrong. This is a case where whatever you're comfortable with is the best solution. Just because you personally don't know frameworks, or js frontends, doesn't mean the people who do are inferior or less secure.
I guarantee someone who knows how to work a framework can turn out the same work much more quickly and more maintainable than someone who is working from Vanilla PHP and having to implement basic logins and email templates on their own. And a "throwaway project" can also be turned into something customer facing much more quickly as well.
I agree, you don't need to pick bleeding edge tech, but you should pick something stable and well documented and run with it rather than basically having to rewrite the same project in the framework once you've got it up and running in vanilla PHP.
I guarantee someone who knows how to work a framework can turn out the same work much more quickly and more maintainable than someone who is working from Vanilla PHP and having to implement basic logins and email templates on their own. And a "throwaway project" can also be turned into something customer facing much more quickly as well.
I agree, you don't need to pick bleeding edge tech, but you should pick something stable and well documented and run with it rather than basically having to rewrite the same project in the framework once you've got it up and running in vanilla PHP.
Please correct me if I am wrong, but as far as I remember the combination of PHP and sqlite fails fairly quickly when if comes to concurrent users?
Don't get me wrong, I am very fond of sqlite, but to use it efficiently you have to manage the connections to the database and from what I have heard, that doesn't work particularly well with PHP.
This doesn't mean that the above recommendation is wrong (in fact, I used similar approaches in the past), I just thought that it should be mentioned and if someone wants to build something that has a lot of concurrent users by design, he knows which part will be the first bottle neck.
Don't get me wrong, I am very fond of sqlite, but to use it efficiently you have to manage the connections to the database and from what I have heard, that doesn't work particularly well with PHP.
This doesn't mean that the above recommendation is wrong (in fact, I used similar approaches in the past), I just thought that it should be mentioned and if someone wants to build something that has a lot of concurrent users by design, he knows which part will be the first bottle neck.
Sqlite's limitations have nothing to do with PHP. But you're correct that it's not intended for use as a multi user database. The limitation is in concurrent writes. If your app is read-oriented, then there is not a problem.
However, I'd personally always use postgres in this case, myself.
However, I'd personally always use postgres in this case, myself.
>Your customers don't care what language it's in or whether the code is beautiful.
Yes, but the person who has to code it cares. No reason to choose the worst of widely used programming languages and the worst possible database for asynchronous read/write patterns inherent to web apps, except as an exercise in masochism.
Yes, but the person who has to code it cares. No reason to choose the worst of widely used programming languages and the worst possible database for asynchronous read/write patterns inherent to web apps, except as an exercise in masochism.
This might be true if you're creating a very simple web site that is never meant to be a real app. If you're creating a more complex web app, with authentication, user management, billing, admin pages, etc. you are better off with frameworks such as Laravel, Symphony or Slim if you are using PHP.
This is correct.
...it is also why php is not really any significantly better choice than any other framework/language combination.
The benefits of ‘plain php’ (simplicity) disappear quite quickly when you’re doing anything non trivial.
I would never choose php without one of those framework stacks; it doesn’t scale, its prone to hideous security issues and its a fugly mess of reinventing the wheel.
Frankly, anyone doing this these days has no idea what they’re doing.
...it is also why php is not really any significantly better choice than any other framework/language combination.
The benefits of ‘plain php’ (simplicity) disappear quite quickly when you’re doing anything non trivial.
I would never choose php without one of those framework stacks; it doesn’t scale, its prone to hideous security issues and its a fugly mess of reinventing the wheel.
Frankly, anyone doing this these days has no idea what they’re doing.
Let's be frank. This is a place for marketing the newest thing where skepticism and scrutiny is not welcome and likely to be dismissed as 'grey beards' and 'people scared of change'.
So there is never any scrutiny, no experienced person is going to expose themselves to ridicule so all the problems are discovered years later only for a new one to take its place.
Ruby for instance has huge deployment problems, why the hell do you need a build environment on deployment and expose end users to installing hundreds of gems that may need to be compiled and can fail anytime? Same with the wild lands of NPM. It's as if people have endless time to go down all the rabbit holes.
On the other hand Facebook, Wikipedia, Wordpress, Slack and some of the most scalable sites online today use PHP. Yet according to the the hivemind PHP is somehow a disaster, and the next over-engineered complexity is the panacea. This is just not credible.
Unless there can be a way to apply scrutiny during the hype phase the cycle of over-engineering, needless complexity and offloading bad engineering on end users is going to continue.
So there is never any scrutiny, no experienced person is going to expose themselves to ridicule so all the problems are discovered years later only for a new one to take its place.
Ruby for instance has huge deployment problems, why the hell do you need a build environment on deployment and expose end users to installing hundreds of gems that may need to be compiled and can fail anytime? Same with the wild lands of NPM. It's as if people have endless time to go down all the rabbit holes.
On the other hand Facebook, Wikipedia, Wordpress, Slack and some of the most scalable sites online today use PHP. Yet according to the the hivemind PHP is somehow a disaster, and the next over-engineered complexity is the panacea. This is just not credible.
Unless there can be a way to apply scrutiny during the hype phase the cycle of over-engineering, needless complexity and offloading bad engineering on end users is going to continue.
[deleted]
Since you listed PHP - take a lot at Laravel (https://laravel.com/)
Like Rails, you can get a a site/app up in minutes. .
Like Rails, you can get a a site/app up in minutes. .
Symfony 4 can be spun up as fast as Laravel 5 and (this is my opinion) Symfony has all the benefits of Laravel with a better ORM (if you want it) and they have never broken backwards compatability in my experience.
Throw in the utterly fantastic documentation (that is both more detailed, thorough and better organised) and I'm not sure why Laravel took off the way it did.
I used Laravel for 3 years at a previous job (from 3 to 4 to 5) and I still think Symfony is the better basis for anything that isn't a relatively small application.
Also Symfony components are genuinely de-coupled, documented on how to use them stand alone and useful for that (I gradually brought them in on an inherited project with few issues).
Throw in the utterly fantastic documentation (that is both more detailed, thorough and better organised) and I'm not sure why Laravel took off the way it did.
I used Laravel for 3 years at a previous job (from 3 to 4 to 5) and I still think Symfony is the better basis for anything that isn't a relatively small application.
Also Symfony components are genuinely de-coupled, documented on how to use them stand alone and useful for that (I gradually brought them in on an inherited project with few issues).
I have a huge complex behemoth of an application which is written in CodeIgniter 3 with a whole bunch of changes that I have made over the years to the core. To call it CI 3 is a bit of an understatement.
I hadn't upgraded sooner because it had worked, but then due to issues with my stack. I decided recently to start from scratch and upgrade my toolset as well.
So I was deciding to either go symfony or laravel. Laravel won by a huge margin. From the perspective of a newbie. Even though I have 10+ years developing in PHP, I like to debase myself and approach with no baggage.
Laravel has so many more tutorials than Symfony 4 on Youtube. I wanted to learn and very very fast. So going through videos in 2x speed and getting the gist of how things worked was great.
Continuing on, there were many tutorials which had actually built apps using Laravel 5.5/5.6. So I was able to quickly get up to speed using Validation, Eloquent, Passport, Middlewares, Query Builder, etc.
On the documentation side. It's very easy to use and describes simply how to get things done.
Next was that Laravel had VueJS integration. So out of the box, I could have an SPA and use Laravel effectively as an API. Of course, right now I am one developer so 1 codebase is fine. But later on, if I need to split and have two codebases (VueJS front-end, Laravel API), then I can do that.
With Laravel I've gone from writing straight SQL to using the ORM. Which surprisingly for me, reduced my codebase by a significant margin and surface area for bugs.
I have found that there are a lot of Laravel composer packages compared to what I was using before and again makes my life so much easier.
Finally, there is a bit of synergy between Vue and Laravel. For example, I'm able to post a form with Vue using Vee-Validate for the validation. Then get laravel to post back any errors for Vee-Validate to consume. In jQuery and using my old codebase. I had to jump through hoops to get it done and much more code.
I will also say, that I had actually decided to go with Symfony in the beginning. The main reason was that Symfony was more pure and I have developer friends who recommended it as the way forward.
> and I'm not sure why Laravel took off the way it did.
It took off because with Symfony, try as I might. I just couldnt get on with it. It wasn't as pleasant experience with Laravel and honestly. Even if I persisted. The time that I took to go from zero, to duplicating my own stack was a few weeks.
I don't think I could have done that with Symfony. Yes, I could probably achieve the same result with Symfony. But not in the same amount of time.
As still a new laravel developer. I want to be able to deploy new features very fast. I can do this now.
I hadn't upgraded sooner because it had worked, but then due to issues with my stack. I decided recently to start from scratch and upgrade my toolset as well.
So I was deciding to either go symfony or laravel. Laravel won by a huge margin. From the perspective of a newbie. Even though I have 10+ years developing in PHP, I like to debase myself and approach with no baggage.
Laravel has so many more tutorials than Symfony 4 on Youtube. I wanted to learn and very very fast. So going through videos in 2x speed and getting the gist of how things worked was great.
Continuing on, there were many tutorials which had actually built apps using Laravel 5.5/5.6. So I was able to quickly get up to speed using Validation, Eloquent, Passport, Middlewares, Query Builder, etc.
On the documentation side. It's very easy to use and describes simply how to get things done.
Next was that Laravel had VueJS integration. So out of the box, I could have an SPA and use Laravel effectively as an API. Of course, right now I am one developer so 1 codebase is fine. But later on, if I need to split and have two codebases (VueJS front-end, Laravel API), then I can do that.
With Laravel I've gone from writing straight SQL to using the ORM. Which surprisingly for me, reduced my codebase by a significant margin and surface area for bugs.
I have found that there are a lot of Laravel composer packages compared to what I was using before and again makes my life so much easier.
Finally, there is a bit of synergy between Vue and Laravel. For example, I'm able to post a form with Vue using Vee-Validate for the validation. Then get laravel to post back any errors for Vee-Validate to consume. In jQuery and using my old codebase. I had to jump through hoops to get it done and much more code.
I will also say, that I had actually decided to go with Symfony in the beginning. The main reason was that Symfony was more pure and I have developer friends who recommended it as the way forward.
> and I'm not sure why Laravel took off the way it did.
It took off because with Symfony, try as I might. I just couldnt get on with it. It wasn't as pleasant experience with Laravel and honestly. Even if I persisted. The time that I took to go from zero, to duplicating my own stack was a few weeks.
I don't think I could have done that with Symfony. Yes, I could probably achieve the same result with Symfony. But not in the same amount of time.
As still a new laravel developer. I want to be able to deploy new features very fast. I can do this now.
Fair enough, it founds like you found a good fit for your use case (and that's a good thing).
In a year or two when you have a bit of time it might be worth going back and having a look at Symfony anyway, you'll likely find that going from Laravel to Symfony will make more sense than CI to Symfony (underneath Laravel uses a fair few symfony things).
In a year or two when you have a bit of time it might be worth going back and having a look at Symfony anyway, you'll likely find that going from Laravel to Symfony will make more sense than CI to Symfony (underneath Laravel uses a fair few symfony things).
PHP is like the Javascript of backend. Hate it all you want but there is nothing better to get shit done esp if you're a small team or working solo.
Also it is super flexible too (much like JavaScript and babel) as in you can write strict OOP code or you can write plain php code inside Html in static files.
Also it is super flexible too (much like JavaScript and babel) as in you can write strict OOP code or you can write plain php code inside Html in static files.
The first paragraph is plain wrong. JS is the JS of frontend because there are no replacements. Use a language compiled to it, but still you'll have to know and use JS. PHP on the other hand is a caricature of a language that you can avoid.
The second paragraph is correct, but it's just equally correct for Python, Ruby, Perl, Lisp, Shell languages etc., as they all support multiline strings and string interpolation too. The only difference is that you'll have to wrap strings in delimiting markers, instead of code with <? ?>.
The second paragraph is correct, but it's just equally correct for Python, Ruby, Perl, Lisp, Shell languages etc., as they all support multiline strings and string interpolation too. The only difference is that you'll have to wrap strings in delimiting markers, instead of code with <? ?>.
Agreed. I've worked with PHP for years. It's not my choice unless it's a requirement. There are plenty of other more durable and scalable languages for the backend (as you've listed) that are just as easy and quick to get going if not more so.
Isn't NodeJS the Javascript of backend?
+1 for NodeJS, seriously no offence to PHP folks, but Nodejs or Python is not much different from PHP in terms of developer productivity.
The reference implementation of PHP, Zend, is objectively not good (blocking I/O) and encourages server side templating, which is basically something you can perfectly do in the client and serve on a CDN at much lower cost (orders of magnitude lower, for processing, memory and transfer).
That being said, doing server side templating in node.js is even worse since it usually wrecks the entire event loop with long lived CPU-bound operations flushing your server performance doing the toilet.
That being said, doing server side templating in node.js is even worse since it usually wrecks the entire event loop with long lived CPU-bound operations flushing your server performance doing the toilet.
What exactly is the benefit of using sqlite over mysql in this case?
Is the 10-15 minutes you might save looking up a quick setup tutorial for the system provided packages really worth the later problems? Postgres is slightly more complex (but pays for itself with additional capabilities), so I can see avoiding that unless your are already familiar with it.
As for PHP, at this point it's not really any easier or harder to get up initially then Python, Ruby or Perl, so it really comes down to personal experience. Whichever one you know best, use it. Whichever framework you know best that has some solutions for what you want to do, use it. That will be quickest.
Is the 10-15 minutes you might save looking up a quick setup tutorial for the system provided packages really worth the later problems? Postgres is slightly more complex (but pays for itself with additional capabilities), so I can see avoiding that unless your are already familiar with it.
As for PHP, at this point it's not really any easier or harder to get up initially then Python, Ruby or Perl, so it really comes down to personal experience. Whichever one you know best, use it. Whichever framework you know best that has some solutions for what you want to do, use it. That will be quickest.
I don't run a MySQL server on my personal computer. I don't want to run one. If I want to start writing code right away to flesh out an idea, SQLite is the tool I can use, it enables me to develop locally with no SSH/FTP overhead or setting up a VM. It lets me start writing code instantly. And it's performant enough for most any MVP, and the SQL dialect is pretty standard so you can upgrade to Postgres or SQLAnywhere or whatever you please when the time comes.
What I hear you saying is:
1. You don't necessarily want to develop in the same environment you deploy to.
2. You don't want to install some things on your development machine.
Together, those are dictating some development directions for you. That's fine. Those are perfectly valid choices. But I think it's easily summed up in your case as "You use sqlite because it fits well with your current development pipeline."
On the flip side, I do development on remote servers using vim. For me, sqlite provides little-to-no additional benefits, since MySQL or Postgres are a package install away (if not already installed), and that's a small price to pay for their additional benefits (for example, a much richer set of data types). At the same time, this type of development pipeline makes certain types of development harder (there's lots of tools for vim/emacs, but some things graphical IDEs provide are harder to achieve).
There is a middle ground, which is emulating the target environment through a VM on the development machine. It should provide the best of both worlds, for a cost of a little most complexity. I've never really gone for that, as I'm happy with the remote dev setup I have, and it's easier not to have to devote local resources to that for me. It's a popular choice as I understand it though.
1. You don't necessarily want to develop in the same environment you deploy to.
2. You don't want to install some things on your development machine.
Together, those are dictating some development directions for you. That's fine. Those are perfectly valid choices. But I think it's easily summed up in your case as "You use sqlite because it fits well with your current development pipeline."
On the flip side, I do development on remote servers using vim. For me, sqlite provides little-to-no additional benefits, since MySQL or Postgres are a package install away (if not already installed), and that's a small price to pay for their additional benefits (for example, a much richer set of data types). At the same time, this type of development pipeline makes certain types of development harder (there's lots of tools for vim/emacs, but some things graphical IDEs provide are harder to achieve).
There is a middle ground, which is emulating the target environment through a VM on the development machine. It should provide the best of both worlds, for a cost of a little most complexity. I've never really gone for that, as I'm happy with the remote dev setup I have, and it's easier not to have to devote local resources to that for me. It's a popular choice as I understand it though.
I think you should be able to understand that sqlite's "the database is a file, ONE file" is superior to getting a fully configured and setup mysql up and running in speed, ease, and simplicity. Of course, it presents limits in terms of scalability (however because it is linked into the application rather than using TCP, if you want to do 400 sql queries per page view sqlite will be MUCH faster than mysql or postgres is going to be)
And in fact Sqlite is linked with the application, so it presents a development environment much more consistent with production (if that's also using sqlite of course) than any mysql or postgres ever will.
And in fact Sqlite is linked with the application, so it presents a development environment much more consistent with production (if that's also using sqlite of course) than any mysql or postgres ever will.
> What exactly is the benefit of using sqlite over mysql in this case?
I'll just let you read this: https://www.sqlite.org/whentouse.html
I'll just let you read this: https://www.sqlite.org/whentouse.html
I usually go for Postgres, but I suppose one advantage is that backing up involves the filesystem rather than figuring out how to do a db dump. Not entirely sure if it's that simple though.
And plus, it works on cheap shared websites that can cost $10 a year + domain name.
Isn't the "PHP works on cheap hosting" schtick a bit dated now you can get a dual-cpu VPS with 8GB RAM at hetzner.com for 8.90 Euros per month? Commodity hosting now makes JVM apps feasible at the lowest price points.
8.90 EUR per month is about $130 a year, so still an order of magnitude more expensive than cheap PHP hosting.
I was just going for a figure similar to the $10/month cited. You can get a 2GB RAM VPS at Hetzner for as little as 2.50 Euros per month.
The cited price was $10/year, not $10/month. That's a huge difference.
Ok, so yesterday's shared hosting prices are today's VPS rates. The point is they've both become commoditised so the PHP/cheap hosting argument is no longer valid.
So instead of admitting mistake you insist that 10x higher prices are somehow invalid argument. You have convinced me!
Just wait until you see cloud pricing ! That is far "superior" (you know, bigger numbers) than either of the quoted prices.
[deleted]
s/php/python and flask or django, depending on the project/ and i agree with the whole comment!
And it makes more sense as OP mentioned Django, not PHP.
[deleted]
Ok. But that does not mean that you have to use the worst thing that is out there.
Why not Python?
Why not Python?
it's worse to you, not the client. client actuality doesn't care and PHP is legacy I guess?
Actually they do if they have to maintain it or want hire really good developers to maintain it. Not saying PHP doesn't meet those criteria, it might in a given region or situation, but just saying your dismissal of this consideration is way off base. Good luck hiring anyone passionate about good software development or recently graduating from decent CS department to work on your PHP apps. I'm sure you are a great developer with a real passion for your craft but you do realize that plus PHP makes you a very uncommon find, right?
"plus PHP makes you a very uncommon find, right"
What? Half the programmers I know in NYC write PHP. The other half write a combo of Java/C#/Python. These aren't programmers working for startups - they are working for companies and the government.
PHP is used everywhere. Except maybe in SFO (and surrounding area).
I mean look at the job listings for NYC, DC, Miami, Baltimore, Louisville, etc, etc.
Look I know this board is focused on Silicon Valley, but it's a big world out there.
What? Half the programmers I know in NYC write PHP. The other half write a combo of Java/C#/Python. These aren't programmers working for startups - they are working for companies and the government.
PHP is used everywhere. Except maybe in SFO (and surrounding area).
I mean look at the job listings for NYC, DC, Miami, Baltimore, Louisville, etc, etc.
Look I know this board is focused on Silicon Valley, but it's a big world out there.
Calling out the regional dimension to the popularity of PHP is totally valid. I think the thing I'm really reacting to is people repeatedly saying "the client doesn't care" which I vehemently disagree with.
Some clients care. But many don't. They just want something to work.
And even if they did what is wrong about choosing PHP?
And even if they did what is wrong about choosing PHP?
If the client does not not care, why suffer by using something that is worse for you? I mean, you might as well use something that you like.
I don't get the logic here.
Another thing is that, if it it worse for you, it is automatically worse for the client. I am not sure why it is so hard to see. if your tool is bad, then your work ll suffer, and thus the client. So it is worse for them also..
I don't get the logic here.
Another thing is that, if it it worse for you, it is automatically worse for the client. I am not sure why it is so hard to see. if your tool is bad, then your work ll suffer, and thus the client. So it is worse for them also..
liking php is unfathomable
In many areas of the US (the entire west coast for example), PHP is dead - plain and simple. Independent of whether it is good or not, selecting dead or obscure technologies for your clients is completely irresponsible and leaves them with a maintenance catastrophe just because you like php. Yes there is a lot of hipster-ism out there in platform choice but there are plenty of mature, fast, and popular options out there. PHP is not one of them.
PHP is not mature or fast or popular? And PHP is very far from dead no matter where you are. In fact is getting a lot more interest now since PHP 7.
If you don't like PHP that's one thing but what you said is just wrong.
If you don't like PHP that's one thing but what you said is just wrong.
PHP isn't dead, and it will never be dead, but as a long time and continuing professional Perl developer myself, let me tell you that you're better off just accepting that your language of choice isn't in vogue anymore.
It's not all bad once you're on the ass-end of history. I'm sure you can easily identify a few negatives being the language de jour bring (such as lots of shitty programmers joining the community all the time). Welcome to middle-age. ;)
It's not all bad once you're on the ass-end of history. I'm sure you can easily identify a few negatives being the language de jour bring (such as lots of shitty programmers joining the community all the time). Welcome to middle-age. ;)
Perl 5 is pulling me like a superstrong magnet. I haven't had time to read the basics and things like choosing the correct sigil + accessor trim me up, but still, it has many niceties. To begin with, you can have a statement "use v5.x;" and be done with which interpreter problem: it can tell you it needs sth. different, and does not fail because you have python3 to be 3.x, but the script needs 3.x+y, or you have the shebang as python3.x but the system has 3.x+y which is compatible, but you can only have one full path in the shebang... Then the context variable $_ is just lovely. The availability of mature libraries for everything is a trait Perl shares with a small number of languages. Its integration to Unix and its expressivity are second to none. The documentation, while not as accessible as Emacs', is available on you computer offline in man pages, and perldoc can give you proper docs on functions (unlike crappy help() in Python which never shows you anything useful and you have to go to the docs, usually online), add to that POD being a very nice way to add documentation to your scripts and also view them (if its in the path you can "perldoc <script>" and get help. And once you know your way around perl* man pages, you can just program independently, with little or no need to go online for Perl stuff. All niceties other languages/communities could've had, but just don't, because, well IDK why.
I'm a 25yo, so when I started programming Perl hatred was the hot thing already. Well, luckily as a curious person I discovered its just baseless cargo cult. Perl is one of the best tools to have in your toolbox.
I'm a 25yo, so when I started programming Perl hatred was the hot thing already. Well, luckily as a curious person I discovered its just baseless cargo cult. Perl is one of the best tools to have in your toolbox.
Well said!
There are many successful companies and start ups that use PHP. The same way they exist for other languages and platforms.
No start up became a unicorn because of the programming language they used.
No start up became a unicorn because of the programming language they used.
With the possible exception of Clojure :). See Paul Graham on Lisp as the secret weapon.
This is just bs. PHP is thriving everywhere expect Silicon Valley.
I don't know which planet you're living on but all you need to do is search Indeed.com for title:php and you'll find PHP is up there with Java, C# and Javascript in terms of the number of jobs. In some countries Java, JS and PHP are the only languages used in any significant numbers. Likewise in more technologically advanced countries once you get away from the tech hubs. I'm not a fan of PHP and I wish it was true but dead it certainly ain't.
For some reason people seem to constant doubt Ruby-ists and Rails Devs.
I completely get that other languages have huge benefits over Ruby. Golang being compiled or Java running anywhere, etc... And ruby is slow, totally understood.
But if youre talking about getting a functioning webapp up and running quickly... no way anyone is beating a Rails dev in setting one up. The piping and scaffolding are all built in and the gem ecosystem (for web apps specifically) is so well maintained and robust that you can drop it in to your app and get a functioning product with ease.
I know that's a loaded statement bc Rails becomes not so great in other cases like building speedy backend jobs. But for a small user-facing web app it's hands down the best.
I completely get that other languages have huge benefits over Ruby. Golang being compiled or Java running anywhere, etc... And ruby is slow, totally understood.
But if youre talking about getting a functioning webapp up and running quickly... no way anyone is beating a Rails dev in setting one up. The piping and scaffolding are all built in and the gem ecosystem (for web apps specifically) is so well maintained and robust that you can drop it in to your app and get a functioning product with ease.
I know that's a loaded statement bc Rails becomes not so great in other cases like building speedy backend jobs. But for a small user-facing web app it's hands down the best.
I’d say the slowness of Ruby is really over exaggerated. For most web applications it’s good enough, and the speed of development (how fast you can ship) almost always outweighs any costs from it being slow.
You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later.
I’ve worked on all sorts of applications from corporate CRUD to mobile billing gateways written in Ruby (usually Rails), and in very few cases has Ruby itself been the bottleneck.
You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later.
I’ve worked on all sorts of applications from corporate CRUD to mobile billing gateways written in Ruby (usually Rails), and in very few cases has Ruby itself been the bottleneck.
There are some properly large companies like github and shopify that run a large rails stack, it seems to work out pretty well for them. At my current workplace we have some streaming servers pushing about 15 gigabyte/second at peak load and the ruby processes easily saturate the available bandwidth on the EC2 instances. Like you say, the slowness of Ruby is greatly exaggerated. Sure we could rewrite the whole thing in Go/C++/Rust/etc, but it would not work any better and the gain of using 10% CPU instead of 20 is not really relevant since it's the NIC that is the bottleneck.
I second that resources consumption with Rails on the production system is only a problem in specific settings (e.g. when your business model depends on many cheap transactions, or when you are running on diverse sets of hosts outside of your control… I'm looking at you, GitLab).
Nonetheless, as a junior Rails developer coming into a 5 people team on a mid-sized project, I saw a diverse set of performance problems during the development phase. E.g. asset pipelines that take ages to compile so that rapid development cycles become impossible or a test suite that took heroic efforts to get down to 15 minutes despite not really doing much computationally-wise. I'm open to alternative interpretations, but I've got the impression that in more performance oriented frameworks the best practice would not turn out to be setting up and tearing down half your server stack before and after each controller test, but instead we would have chosen abstractions that can be plugged together more efficiently.
Nonetheless, as a junior Rails developer coming into a 5 people team on a mid-sized project, I saw a diverse set of performance problems during the development phase. E.g. asset pipelines that take ages to compile so that rapid development cycles become impossible or a test suite that took heroic efforts to get down to 15 minutes despite not really doing much computationally-wise. I'm open to alternative interpretations, but I've got the impression that in more performance oriented frameworks the best practice would not turn out to be setting up and tearing down half your server stack before and after each controller test, but instead we would have chosen abstractions that can be plugged together more efficiently.
I think the rise of Mastodon is really pouring some hot water on that meme. Lots of really small VPSs are running some fairly big instances. Although I'm only personally using one of them, it's very fast, and the general view is that isn't unusual.
I get that it won't hit Twitter scale but that matches the majority of "how do I build a prototype" use cases.
I get that it won't hit Twitter scale but that matches the majority of "how do I build a prototype" use cases.
"Twitter scale" wasn't so much a Ruby/Rails problem as it was an RDBMS (write-many + read-many = road to fail) and writing their own in-house message queue problem. Starling performed worse than just about everything else out there (and their Scala replacement Kestrel isn't much better).
One really insipid blog post and thousands of mindless followers later and the damage to Rails has been done.
That's not to say Rails doesn't/didn't have other issues -- it did. It's just telling that Twitter is the first example people reach for instead of anything else.
One really insipid blog post and thousands of mindless followers later and the damage to Rails has been done.
That's not to say Rails doesn't/didn't have other issues -- it did. It's just telling that Twitter is the first example people reach for instead of anything else.
Agreed. I've been working mostly in Ruby since 2006, over hundreds or thousands of apps, depending on how you count, and I have only worked on 2 apps that actually had scaling problems with Ruby. The rest were 100% improperly designed or scaled databases.
Twitter is certainly of a scale that I would not be using Ruby on the primary load points. But even billion dollar companies don't often reach that scale.
Twitter is certainly of a scale that I would not be using Ruby on the primary load points. But even billion dollar companies don't often reach that scale.
at twitter’s scale, its not jus ruby, you would also have problems with php, python, node, and maybe even java. only language that will work well at that point are languages built for concurrencies such as scala, elixir, and go.
Or you break out your infrastructure into smaller components and move the more demanding/critical parts of your infrastructure to that other language and keep everything else you've built!
iirc, the ruby 3x3 benchmark project is getting a ruby game (i think mario) to run at 60fps, and ruby 2.5 already hit that target.
even if it's slow today; the runtime is being improved regularly and making a lot of code just faster with a version bump.
even if it's slow today; the runtime is being improved regularly and making a lot of code just faster with a version bump.
> You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later.
Maybe in an API server. But this is nontrivial in a monolithic application where you end up yakshaving the whole middleware stack to parity just to replace an endpoint.
Maybe in an API server. But this is nontrivial in a monolithic application where you end up yakshaving the whole middleware stack to parity just to replace an endpoint.
Totally agree. Rails is really powerful; it not only gets you up and running fast, but it can carry you very far. Like, years and years. And for a lot of places (like github, hulu) they seem to manage fine with it as their stack.
> Rails becomes not so great in other cases like building speedy backend jobs
Rails is still pretttty good for this. I mean, gosh; maybe not a game engine or something like THAT - but for much of what is done on the web rails can be optimized to complete requests in ~25ms.
> But for a small user-facing web app
"small" as in 95% of websites out there that aren't facebook/google. I mean, shopify handles 80,000/req/sec on a rails stack and they are the backbone of a lot of small (and not so small) e-commerce stores.
> Rails becomes not so great in other cases like building speedy backend jobs
Rails is still pretttty good for this. I mean, gosh; maybe not a game engine or something like THAT - but for much of what is done on the web rails can be optimized to complete requests in ~25ms.
> But for a small user-facing web app
"small" as in 95% of websites out there that aren't facebook/google. I mean, shopify handles 80,000/req/sec on a rails stack and they are the backbone of a lot of small (and not so small) e-commerce stores.
I started building a SaaS in Java/Spring and months in realised Ruby/Rails would have been stunningly faster to get the same result. The full write-up is here for reference http://tayler.io/5-lessons-learned-as-an-indie-hacker/
Your site completely refuses to load with noscript.
Are you sure the complexity needed for it warrants this?
Are you sure the complexity needed for it warrants this?
> no way anyone is beating a Rails dev in setting one up
I disagree. Elixir/Phoenix is as simple as Ruby/Rails and an order of magnitude more performant out of the box. Especially if you already know Ruby and the basics of functional programming. Plus, unlike Rails, you probably won't need separate servers for background jobs, websockets and caching.
I disagree. Elixir/Phoenix is as simple as Ruby/Rails and an order of magnitude more performant out of the box. Especially if you already know Ruby and the basics of functional programming. Plus, unlike Rails, you probably won't need separate servers for background jobs, websockets and caching.
Sorry to fact check here but on my Rails app I am getting 200ms return times. This is running a web application and a few hybrid mobile applications. Are you saying that basically out of the box with Elixir/Phoenix I would get 20ms return times? That would be amazing but I find that highly unlikely.
Yes, and likely faster.
http://www.akitaonrails.com/2015/10/27/how-fast-is-elixir-ph...
http://www.akitaonrails.com/2015/10/27/how-fast-is-elixir-ph...
That’s quite interesting. I’m going to have to give this a try under real world condition. This gives a pretty good argument for massive improvement.
For my load balancer heartbeat checks, I'm returning responses in 200µs.
That’s a highly unrealistic real world scenario. I’d like to see a page under load with actual queries. Heartbeat checks are far from actual real world examples of much of anything.
I guess my point was: that’s the baseline. It’s an order of magnitude faster the 20ms your saying is unlikely. That leaves a lot of headroom for hitting the db and things done. The api I’m working on isn’t currently being hit super hard, but for most of my endpoints 25ms is pretty average.
And if the next order of magnitude of performance is needed, there's always Crystal
But since it is much newer, the docs and examples are much thinner than Phoenix.
Plus, except for unoptimized database actions (which would equally affect Crystal), Phoenix responses are usually sub 200ms. Some are sub 1ms. So it really isn't in need of performance increase.
Ecto, however, is really not pleasant imo.
Plus, except for unoptimized database actions (which would equally affect Crystal), Phoenix responses are usually sub 200ms. Some are sub 1ms. So it really isn't in need of performance increase.
Ecto, however, is really not pleasant imo.
I looked into rails in some detail about a year ago, and I think it's the only pretty good solution for this I've come across—but there's a steep up front cost in learning/setup etc. (or so it seems).
It's best to pick a project and try to build it, rather than learn things from the outside. In isolation, Ruby can be annoying to learn because it's syntactic sugar seems unnecessary. In context of an app, though, it's great. The sugar makes sense.
Rails has a bit of a learning curve, but that learning curve is well rationalized. To borrow a Steve Jobs-ism: you're starting on the 10th floor, when everyone else is starting on the 2nd floor. Out of the box, you get a killer asset pipeline and complete MVC system that's standardized and conventional.
You can throw together a well built webapp without cutting corners in a fraction of the time doing it by hand. Things like a solid REST API practically come free with Rails. That's really valuable.
Rails has a bit of a learning curve, but that learning curve is well rationalized. To borrow a Steve Jobs-ism: you're starting on the 10th floor, when everyone else is starting on the 2nd floor. Out of the box, you get a killer asset pipeline and complete MVC system that's standardized and conventional.
You can throw together a well built webapp without cutting corners in a fraction of the time doing it by hand. Things like a solid REST API practically come free with Rails. That's really valuable.
What are the best resources to learn Ruby/Rails these days?
https://www.railstutorial.org/book is quite good
This is what I used to jump from "I've hacked on a rails 3 app and gone through some ruby Katas" to "I am building out a full fledged SaaS product in a Rails 4 app as technical co-founder".
Highly recommended.
Highly recommended.
I, personally, just used the Rails docs, and watched DHH's introduction. The Rails guides are really good (the official guides, that is).
Pick up rails book from pragmatic bookshelf. Give it a quick read. Then watch railscast videos. Then to rails doc and gorails.
Another vote for Gorails. It's certainly the next step from beginner Rails dev to, well, not beginner.
The community is so big, and so focused on conventions over configurations, usually googling "rails <questions>" returns a LOT of links to stack overflows and blogs that clearly explains everything.
Rails offer so much syntactic sugar/plug and play gem systems that usually things are setup in fewer lines of code than anywhere else.
The downside is that it's easy to build something while barely having any idea how it works, but if you want something up quickly (or if you already know how things work) then it's perfect.
The downside is that it's easy to build something while barely having any idea how it works, but if you want something up quickly (or if you already know how things work) then it's perfect.
Yeah, I never found Rails as easy to learn as others did. Maybe it’s because I was younger and less experienced than now.
Or maybe I’m dumb.
Or maybe I’m dumb.
There is definitely a learning curve. For me, Rails was unapproachable until I started to give up the idea that I needed a ton of custom stuff in my stack. The "allure" I saw of pulling together a basic routing system and hooking things up by hand completely disappeared after building a pretty substantial web app in _Sinatra_.
Rails makes a lot of decisions for you, but the decisions it makes are the _right_ ones. It's like having a "best practices" box that you can just shove your custom system into, rather than trying to build them in yourself. It's really quite something.
For context: I basically learned Rails by way of building a proof of concept election management system in Rails in about three weeks (more like 1.5 in actual programming time). It also stored votes on a blockchain (ethereum). Even with a relatively complex storage system and interaction model, the Rails best practices left me with a really satisfactory application in no time flat. Perfect for a fast PoC.
Rails makes a lot of decisions for you, but the decisions it makes are the _right_ ones. It's like having a "best practices" box that you can just shove your custom system into, rather than trying to build them in yourself. It's really quite something.
For context: I basically learned Rails by way of building a proof of concept election management system in Rails in about three weeks (more like 1.5 in actual programming time). It also stored votes on a blockchain (ethereum). Even with a relatively complex storage system and interaction model, the Rails best practices left me with a really satisfactory application in no time flat. Perfect for a fast PoC.
Depending on how long ago, I've noticed that the comprehensiveness of third party documentation (i.e. googling "how do I x?") can really change the experience.
My memories of trying to install Linux circa 2000? Not favorable. Though to be fair I was a lot younger then too.
My memories of trying to install Linux circa 2000? Not favorable. Though to be fair I was a lot younger then too.
Laravel. It's PHP and (assuming you know Laravel) you can get a it up in minutes. It's development time is as fast as Rails.
I'm not taking any chips from Rails. Rails was the first and is still one of the best. Just pointing out that there are other frameworks that are designed to move to production fast.
I'm not taking any chips from Rails. Rails was the first and is still one of the best. Just pointing out that there are other frameworks that are designed to move to production fast.
If backend speed/scale is your concern I'd also throw a vote in for Phoenix. Lots of similar heritage to Rails but built on Elixir/Erlang instead.
Phoenix loses my vote for being quick to set up for a web application, because last time I used it, it didn't have a good authentication framework that worked with JSON APIs. What took ten minutes to set up using Devise in Rails took me two days using Coherence in Phoenix.
Unless that's changed since I last tried Phoenix, I'd be hesitant to use it in the same niche as Rails.
Unless that's changed since I last tried Phoenix, I'd be hesitant to use it in the same niche as Rails.
I'm a huge fan of Phoenix, in part because it addresses the main issue I had with Rails (too much magic).
But I do agree that losing the huge ecosystem of gems is a significant downside. Hopefully that'll change over time, because other than that, Phoenix really feels like the next iteration of Rails to me.
But I do agree that losing the huge ecosystem of gems is a significant downside. Hopefully that'll change over time, because other than that, Phoenix really feels like the next iteration of Rails to me.
That's my biggest gripe with Phoenix--so much good stuff can't be used. I understand that sometimes moving on the next thing requires this, but man, it isn't just Rails that has tremendous value when creating a web app. The entire ecosystem has so much good "drop in"/"near drop in" functionality.
Guardian has worked great for us for JWT auth
Well, here's one reason: the amount of time saved when standing up a webapp on Rails is absolutely insignificant compared to the life of that webapp in all situations where that webapp is anything serious.
Not to say that Rails apps aren't serious! I'm just saying that the time saved in standing up a webapp with Rails vs., say, Java, is miniscule compared to the develooment life of that application, overall.
In short: you don't save any time at all, in the big picture, and now you have all the long-term disadvantages of Ruby.
Not to say that Rails apps aren't serious! I'm just saying that the time saved in standing up a webapp with Rails vs., say, Java, is miniscule compared to the develooment life of that application, overall.
In short: you don't save any time at all, in the big picture, and now you have all the long-term disadvantages of Ruby.
Ah, that's an interesting perspective. Having written and supported websites in both Java and Ruby (plus some other languages), I think that your perspective is valid. Long term costs are worth considering. However, sometimes you can take a long term hit in order to deliver quickly.
> compared to the life of that webapp in all situations where that webapp is anything serious.
Actually there is a situation where the short term life of the webapp matters far more than the long term. That's when you are not sure if there is going to be a long term. This could be a startup, a spike to explore a new business model, or even just a prototype of an internal app.
In all those cases, delivering something that has value in a short time outweighs the value of something that might be more supportable/extensible in the long term.
> compared to the life of that webapp in all situations where that webapp is anything serious.
Actually there is a situation where the short term life of the webapp matters far more than the long term. That's when you are not sure if there is going to be a long term. This could be a startup, a spike to explore a new business model, or even just a prototype of an internal app.
In all those cases, delivering something that has value in a short time outweighs the value of something that might be more supportable/extensible in the long term.
You're absolutely right.
We should all over engineer our applications by picking the most complicated stack possible because the long term goal may slightly benefit the short term goal of you know.. actually making money out of our business.
Why pick a simple Rails + Postgres stack when you can setup Oracle + Java because you will require enterprise level scaling for your first 1-100k users
Oh and just for the record, I am sure you are already aware but Rails gets you very..very far. Github, Gitlab, Shopify, AirBnb, Basecamp, Groupon,.. I could go on.
My vote goes to rails.
We should all over engineer our applications by picking the most complicated stack possible because the long term goal may slightly benefit the short term goal of you know.. actually making money out of our business.
Why pick a simple Rails + Postgres stack when you can setup Oracle + Java because you will require enterprise level scaling for your first 1-100k users
Oh and just for the record, I am sure you are already aware but Rails gets you very..very far. Github, Gitlab, Shopify, AirBnb, Basecamp, Groupon,.. I could go on.
My vote goes to rails.
That's like saying that php is a good choice because so many sites use it. Php is never a good choice. Neither is Rails.
Shower me with downvotes. IDGAF; Ruby is rubbish.
Shower me with downvotes. IDGAF; Ruby is rubbish.
I entirely disagree with this.
Rails is optimised for fast development. That isn’t just about first bring-up, but about long-term velocity too. You will almost certainly save time over pretty much any other available solution, even over the long term.
Where Rails and Ruby fall down is going to be in performance and complexity. If your “simple” web app becomes a sprawling and complex mess, Rails won’t deal with that elegantly. And if you suddenly have to scale to millions of users, you might struggle.
Rails is optimised for fast development. That isn’t just about first bring-up, but about long-term velocity too. You will almost certainly save time over pretty much any other available solution, even over the long term.
Where Rails and Ruby fall down is going to be in performance and complexity. If your “simple” web app becomes a sprawling and complex mess, Rails won’t deal with that elegantly. And if you suddenly have to scale to millions of users, you might struggle.
Everytime I say anything on this orange website anymore it is immediately voted down.
I guess the orange website isn't for me anymore.
I guess the orange website isn't for me anymore.
Well, your comment contained a bit of a generalisation. It may or may not be true depending on the size of the app, its purpose, the number of developers, their level of experience, and a bunch of other factors.
The response contained a generalisation too. Horses for courses.
The response contained a generalisation too. Horses for courses.
I agree.
I'd describe my professional experience with Rails as: Rails optimizes for Day 1. Devise is a great example.
But I left Rails when I couldn't help but notice that it tends to break down over time without eternal vigilance. And even simple tasks required me to hold quite a bit of Rails trivia in my head.
These days I'm far less likely to give up simplicity so easily.
I'd describe my professional experience with Rails as: Rails optimizes for Day 1. Devise is a great example.
But I left Rails when I couldn't help but notice that it tends to break down over time without eternal vigilance. And even simple tasks required me to hold quite a bit of Rails trivia in my head.
These days I'm far less likely to give up simplicity so easily.
Assuming we’re talking about a startup, the expected lifetime of your product is ~0 and so is the number of customers. If you’re somehow lucky enough to ever have so many users that you have issues with rails, you will have the money (VC or otherwise) to deal with it.
The benefit of Golang isn't that it's compiled. It's that it has a good IO and concurrency model and the language is strict enough to force certain good practices on developers.
IMO it would be almost as good even if the code execution were as slow as Python or Ruby.
IMO it would be almost as good even if the code execution were as slow as Python or Ruby.
I hear this a lot about Go, but doesn't the webserver handle concurrency for you in most cases? I don't do a whole lot of explicit threading work when I write webservers in Java for example. Or is there something I'm missing that you use the Go primitives for in these cases?
I'm not as familiar with Java but It's more about concurrency than threads. I have more familiarity with Python, so using that as an example...
There are Tornado and asyncio libraries for Python that give you asynchronous networking. But you have to totally rework how you write Python code within those request handlers to factor out blocking IO which makes using existing libraries for DB and such a pain.
Go is built from the ground up to handle IO like that asynchronously so all of your libraries and stuff will just work in that context.
NodeJS is similar to Go in that regard, but the JS language has baggage that gives you weird blends of callback asynchronicity mixed with async/await and it generally just doesn't feel as nature as Go.
Sometimes a simple request/response model isn't enough. Maybe you need a streamed (chunked encoding) API or WebSockets where the performance for massive numbers of connections using threaded servers is going to tank quickly compared to a language like Go that handles the IO and concurrency better from the ground up.
There are Tornado and asyncio libraries for Python that give you asynchronous networking. But you have to totally rework how you write Python code within those request handlers to factor out blocking IO which makes using existing libraries for DB and such a pain.
Go is built from the ground up to handle IO like that asynchronously so all of your libraries and stuff will just work in that context.
NodeJS is similar to Go in that regard, but the JS language has baggage that gives you weird blends of callback asynchronicity mixed with async/await and it generally just doesn't feel as nature as Go.
Sometimes a simple request/response model isn't enough. Maybe you need a streamed (chunked encoding) API or WebSockets where the performance for massive numbers of connections using threaded servers is going to tank quickly compared to a language like Go that handles the IO and concurrency better from the ground up.
On a side note, if someone asks me to prototype anything on Java world, will pick Grails. Getting a webpage up and running in Grails is so easy.
Which version of Grails was that? If you mean version 3, why is virtually no-one starting new projects in it, or upgraded from v.2 ? Grails 3 looks like nothing more than a wrapper around Spring Boot, so why not just use that? If you're talking about version 2, why has its plugin ecosystem died?
Are you aware that Flask exists for Python? I might take that bet about no one being able to go quicker than a Rails dev.
From the Ruby side Sinatra is just as fast as flask to get something going. Having supported all three ( Rails, flask, Sinatra ) if it's going to be an API. I usually start with Sinatra.
Agreed. Flask or Aiohttp + templating engine of choice + flask-login or aiohttp-security is extremely fast and simple.
Pyramid - https://trypyramid.com/ - lightweight like flask but with that little extra that makes life easier (authentication, sqlalchemy integration). Not as heavy/opinionated as django. In fact, would argue, not opinionated at all.. just the right balance.
You left out persistence, which is the most annoying bit of setting up a Flask project, imo.
You can literally start and publish a C# web app to azure in minutes if you wanted to. They have built in deploy from GitHub.
I usually rip a bunch of stuff out of their default app template and actually get the app doing something useful first before I deploy but it's really easy.
I usually rip a bunch of stuff out of their default app template and actually get the app doing something useful first before I deploy but it's really easy.
Agreed! I have a template built that allows me to spin up a basic web app with all my baseline common dependencies ready to go and a handful of little nice-to-haves in place and deploy to Heroku in well under an hour. I love Rails!
I keep on running into this problem where I try to use a new framework/language for backend, like Go, Kotlin, even Node, but I just get so damn bored with writing the same boilerplate. Say what you will about Rails, but at least the maintainers try to automate the boring parts. Not to mention between Elastic Beanstalk, Heroku and even plain old Capistrano on a VPS, deploying Rails is a breeze. Maybe some people take some perverse joy from writing CRUD operations for the millionth time, but I don't.
I’m curious: once one has written a CRUD app, why can’t they use that as the boilerplate for other CRUDs they need to write? Replace the bits specific to each individual app. If the program is designed in a sufficiently modular fashion, shouldn’t this be doable?
That assumes you're allowed to use the code you wrote in a previous project in your new project.
Eh, are you perhaps hinting at that horrible lawsuit where Oracle sued Google(?) for a lot of money for copying about 9(?) lines of code that was basically a looping routine?
That notwithstanding, I was asking about code that could be considered “boilerplate”, not things that could be considered proprietary business logic. So the code to do a login, or check for cookies, or get something from a db, or anything of that sort should be broadly reusable (for a general CRUD app).
That notwithstanding, I was asking about code that could be considered “boilerplate”, not things that could be considered proprietary business logic. So the code to do a login, or check for cookies, or get something from a db, or anything of that sort should be broadly reusable (for a general CRUD app).
Somewhere around 2006, after my first enthusiasm about Rails I realised I could get almost the same, with a language that is more natural for me, has more developers here, as well as cheap hosting options (less of a concern now) by going with php/symfony.
Later I've been enjoying
- a php microframework that slips my mind
- python/flask/sqlalchemy
- JavaEE (yup, except JSF)
Later I've been enjoying
- a php microframework that slips my mind
- python/flask/sqlalchemy
- JavaEE (yup, except JSF)
Quickly? Firebase + React.
Seriously, don’t overlook this combo. Auth just works. Hosting built in, no backend or database server to maintain. No API, just subscribe to a collection right from the view. It just works (and is easily swapped for the real deal if you need it).
I made a guide/boilerplate to show you how (includes auth, CRUD, full text search, stripe subscriptions):
http://getfirefly.org/
Seriously, don’t overlook this combo. Auth just works. Hosting built in, no backend or database server to maintain. No API, just subscribe to a collection right from the view. It just works (and is easily swapped for the real deal if you need it).
I made a guide/boilerplate to show you how (includes auth, CRUD, full text search, stripe subscriptions):
http://getfirefly.org/
Too expensive to be worth it. I'm totally fine with outsourcing stuff that is difficult and third parties can do better, but in this case the amount of stuff you're playing egregious "cloud" pricing for is too much. Just spend a handful of days learning one of the open source stacks and you'll be set for life. It's totally worth it assuming you'll be making more than 1 app ever.
Firebase's free tier is more than enough to play with an idea, and the next tier up is (100k concurrent users) $25/month ... if that's too expensive then there's something very wrong with your pricing model. Obviously this assumes you're not storing much data per user - you wouldn't build a imgur clone with it - but it's not that expensive for any typical SaaS app.
Concurrent users are not the only limitation. Your app needs to fit the bandwith limits as well. I had to shutdown a very simple app with a few users because of ridiculous billing.
And it's actually way cheaper for small apps if you "upgrade" to the Blaze plan and do pay-as-you-go billing. I often pay between $0 and %0.05/mo...
Full pricing: https://firebase.google.com/pricing/
Full pricing: https://firebase.google.com/pricing/
Guess it depends on what you consider expensive.
For me, time I’m writing unnecessary code or learning libraries I don’t already know is time I’m not spending thinking about the product. I’m a designer who just wants to ship.
I am open to suggestions though. What would you recommend for, say, auth instead? I’ve tried rails, Django, node/mongo, etc; even hosting a small db on compose.io comes with a chunky base fee, and I still have to do way too much work for user accounts/search/APIs/ORM. There’s a reason Firebase is popular with the yoof.
Change my mind though!
For me, time I’m writing unnecessary code or learning libraries I don’t already know is time I’m not spending thinking about the product. I’m a designer who just wants to ship.
I am open to suggestions though. What would you recommend for, say, auth instead? I’ve tried rails, Django, node/mongo, etc; even hosting a small db on compose.io comes with a chunky base fee, and I still have to do way too much work for user accounts/search/APIs/ORM. There’s a reason Firebase is popular with the yoof.
Change my mind though!
My startup is betting on parse server platform [0].
For us its the most of 2 worlds.
- huge community supporting a codebase initially private
- open source now so you can host it anywhere
- 3rd party online instances to quickly start [1][2]
[0][http://parseplatform.org/]
[1][https://sashido.io]
[2][https://back4app.com]
[3][https://https://www.nodechef.com/parse-server]
- huge community supporting a codebase initially private
- open source now so you can host it anywhere
- 3rd party online instances to quickly start [1][2]
[0][http://parseplatform.org/]
[1][https://sashido.io]
[2][https://back4app.com]
[3][https://https://www.nodechef.com/parse-server]
"Just spend a handful of days learning one of the open source stacks"
Sure, but which one? :)
Sure, but which one? :)
Opensource alternative to firebase: couchdb . Less features but the essentials are there...
If you use couchdb+rxdb, you have the same subscribe-to-collection thing but without the google lock in
While firebase has an expensive first tier, Firestore bills more for what you use, like AWS does.
This.
Maybe I am biased because I develop most of my applications in React. But if you don't want to bother with any backend application and just want to get out quickly, build your React application with Firebase. That's how I do it and that's why I also covered my whole boilerplate process in a comprehensive tutorial [0].
- [0] https://www.robinwieruch.de/complete-firebase-authentication...
Maybe I am biased because I develop most of my applications in React. But if you don't want to bother with any backend application and just want to get out quickly, build your React application with Firebase. That's how I do it and that's why I also covered my whole boilerplate process in a comprehensive tutorial [0].
- [0] https://www.robinwieruch.de/complete-firebase-authentication...
I still love the Meteor framework, even if it's not as popular these days. Auth "just works", The Mongo<->Server<->Client dataflow is super easy, and there's lots of tools to quickly and easily deploy it.
Now that React is supported, it's even easier for throwing together web apps.
Now that React is supported, it's even easier for throwing together web apps.
I just dropped firebase after nearly a month of development. Firestore lacks so many features that i consider basic. For example you can't even do a count query on the db and have jump hoops to even achieve this simple feature.
I was gonna say the same thing. It’s cheap/nearly free if it’s just a little side project or low traffic thing. And a joy of a stack to work in.
yerp, by 2018, UI + SaaS backends is often the easiest way to get something deployed ... provided you want to deploy essentially the same thing other people already have + some customization ..
.. what's going to be neat to see is how that "essentially the same thing" changes over time.
deepstreamhub.com is another neat SaaS that's worth looking into for some cases that Firebase might not handle as well ... there are probably yet other SaaS products that cover other specifics and will be still more in the future..
.. obvious mention re. SaaS products is that they could evaporate at any time. warranty void where prohibited. all states except ... idk, AK, for some reason.
.. what's going to be neat to see is how that "essentially the same thing" changes over time.
deepstreamhub.com is another neat SaaS that's worth looking into for some cases that Firebase might not handle as well ... there are probably yet other SaaS products that cover other specifics and will be still more in the future..
.. obvious mention re. SaaS products is that they could evaporate at any time. warranty void where prohibited. all states except ... idk, AK, for some reason.
the hub product shutdown https://github.com/deepstreamIO/deepstream.io/issues/867
I'm having trouble building with this. Can you elaborate a little bit more about the steps after adding adding all three project. I can't understand this
>> " Now let's connect our databases to our app by adding their "keys" to our app's environment ("env") files. You should generally keep connection keys like this secret, so first we'll rename our environment files to keep them from getting committed into git (the new filenames are listed in .gitignore). "
>> " Now let's connect our databases to our app by adding their "keys" to our app's environment ("env") files. You should generally keep connection keys like this secret, so first we'll rename our environment files to keep them from getting committed into git (the new filenames are listed in .gitignore). "
My fault--I've re-added the sample env files, you can copy these, remove ".example" from the name, and add your keys:
https://github.com/sampl/firefly
Thanks for trying it out!
https://github.com/sampl/firefly
Thanks for trying it out!
> Quickly? Firebase + React.
Came here to recommend this myself.
I built an SPA with React + Firebase (auth, db, hosting, and all) to help my wife and I track our kids allowance and spending in just over a day: https://parentbank.actridge.com/ (did I mention Firebase hosting allows HTTPS on custom domains?)
It's an awesome combo that is seriously under-utilized.
Came here to recommend this myself.
I built an SPA with React + Firebase (auth, db, hosting, and all) to help my wife and I track our kids allowance and spending in just over a day: https://parentbank.actridge.com/ (did I mention Firebase hosting allows HTTPS on custom domains?)
It's an awesome combo that is seriously under-utilized.
Good idea. Gonna look into this!
Just stripe subscription? Customers of my consultancy also require Bitcoin, Wire transfers and other payments. We use http://killbill.io/ now. It supports multi tenancy.
Full-stack Clojure with Clojurescript front-end is about the fastest workflow I’ve ever used. The front-end part in particular with Reagent (a Clojurescript React library) is a very quick workflow compared to all front-end alternatives. There are perhaps more valid options for server, but even still, having the same language in both browser and server is very convenient both for reduction in cognitive dissonance and automatic transfer of language-specific data structures back and forth.
Highly recommend.
I should add that on both server and in browser your code base will usually be a lot smaller than most other languages, which greatly speeds workflow as well. As an example I once ported an Elm project to Clojurescript and it was a 4x reduction in lines.
Using Heroku to just git push the project works well too. Deploys in seconds.
If your project becomes more, it all scales well. Clojure is quite fast compared to Ruby or Python, and Heroku scales with the click of a button. You won’t have to port to a more performant language or host if you suddenly get popular.
Highly recommend.
I should add that on both server and in browser your code base will usually be a lot smaller than most other languages, which greatly speeds workflow as well. As an example I once ported an Elm project to Clojurescript and it was a 4x reduction in lines.
Using Heroku to just git push the project works well too. Deploys in seconds.
If your project becomes more, it all scales well. Clojure is quite fast compared to Ruby or Python, and Heroku scales with the click of a button. You won’t have to port to a more performant language or host if you suddenly get popular.
I've had the same experience. On the front-end, reagent is a joy to use. Haven't found a framework that feels more elegant/smooth than what reagent does with components and hiccup (maybe adding re-frame for state management).
There are some great choices for the server side too. Plus libraries for pretty much every DB. When something is missing, there's definitely a fallback option in Java.
Plus you get hot-reloading on both sides (e.g. boot-reload and ring-reload). And the ability to bundle everything into one neat jar file so the only dependency for deployment is Java.
Here's a getting started project that I found helpful: https://github.com/oakes/full-stack-boot-example
There are some great choices for the server side too. Plus libraries for pretty much every DB. When something is missing, there's definitely a fallback option in Java.
Plus you get hot-reloading on both sides (e.g. boot-reload and ring-reload). And the ability to bundle everything into one neat jar file so the only dependency for deployment is Java.
Here's a getting started project that I found helpful: https://github.com/oakes/full-stack-boot-example
Although Clojure is my favourite language I find web development difficult with it due to auth for which Buddy is the standard. Buddy's integration with Luminus is opaque at best and the Buddy docs themselves I found unhelpful. You're left with the impression that Clojure web development is for experts who already understand how it all works. Total contrast with Rails where there are great resources for average developers and newcomers. I think this stems from the Clojure community's reluctance to embrace web frameworks.
Does Clojurescript support stuff like hot code reloading? And does Clojure have any good framework for an actor system implementation?
Because I've been interesting to get an excuse and try Clojure out and what you're saying is really interesting.
Because I've been interesting to get an excuse and try Clojure out and what you're saying is really interesting.
Clojure has its own very effective strategy for multi-threading, and it is not the actor model. The language is built for concurrency and much careful language design was tailor-made for the challenges on modern threaded applications. Rich Hickey investigated the actor model considerably, and decided on a different model. In the core language, you have the choice of using its normal futures/threads with highly efficient and lock-free data structures, or using core.async, which is a model like Go channels. The latter is particularly popular in the community and generally the recommended approach.
Clojurescript offered the first and still (in my opinion) best option for hot reloading via "figwheel" which nearly all Clojurescript developers use. It automatically updates the UI as you code it.
Clojure, on the server, being a proper lisp with a real REPL, lets you poke and inspect and reload parts of the running program with no recompile cycle. A typical workflow there is to reload individual expressions or functions in the context of the running program to alter behavior as you develop.
Clojurescript offered the first and still (in my opinion) best option for hot reloading via "figwheel" which nearly all Clojurescript developers use. It automatically updates the UI as you code it.
Clojure, on the server, being a proper lisp with a real REPL, lets you poke and inspect and reload parts of the running program with no recompile cycle. A typical workflow there is to reload individual expressions or functions in the context of the running program to alter behavior as you develop.
Yeah, that's nice for multi-threading but it does not seem as good for distributed systems. This is why I still don't know if I should invest in Clojure or Elixir.
Can the REPL on the server be used to update production systems with no downtime?
Can the REPL on the server be used to update production systems with no downtime?
Yes you can easily REPL into a live remote server and work with it while it is running. But more typically, the REPL-driven development happens on your own machine while you build, and then you just deploy the whole app. But it can be useful for remote debugging when necessary.
For distributed computing across multiple machines, you are right that the actor model has an edge there. Most applications don't require that, however. There is however Onyx and other tools for this in Clojure:
http://www.onyxplatform.org/index.html
I think the choice between Clojure and Elixir really comes down to how much your particular idea or requirement genuinely depends on the actor model. The vast majority of applications don't specifically require that, in which case you have more flexibility.
For distributed computing across multiple machines, you are right that the actor model has an edge there. Most applications don't require that, however. There is however Onyx and other tools for this in Clojure:
http://www.onyxplatform.org/index.html
I think the choice between Clojure and Elixir really comes down to how much your particular idea or requirement genuinely depends on the actor model. The vast majority of applications don't specifically require that, in which case you have more flexibility.
I was just looking into Onyx right now actually, haha. It's the first result when googling for distributed clojure. Not quite sold on the model, I don't yet know how the internals work so it feels a bit too magic. But I only got a quick peek so it would be unfair to dismiss it.
The vast majority of apps don't require distribution but I'd like to use a model of computation that would support it when needed so as to avoid large refactoring. And, preferably, allow for code reuse with systems that are distributed.
EDIT: Watching a talk about the internals of Onyx made by the creator. I gotta say, I'm liking it more and more.
The vast majority of apps don't require distribution but I'd like to use a model of computation that would support it when needed so as to avoid large refactoring. And, preferably, allow for code reuse with systems that are distributed.
EDIT: Watching a talk about the internals of Onyx made by the creator. I gotta say, I'm liking it more and more.
Don't forget that with Clojure, anything you would do in Java or on the JVM using any language, you can do in Clojure. So for example, Scala has Akka, a powerful actor model. And of course, you can use that in Clojure if you want:
https://github.com/gaverhae/okku
(This is just one way to use Akka).
https://github.com/gaverhae/okku
(This is just one way to use Akka).
Interesting, okku seems completely outdated but I'll try to look out for an Akka integration as it is a really powerful and stable actor model implementation. Has backpressure and all of the other reactive niceties too.
You might just have converted me to clojure, haha.
You might just have converted me to clojure, haha.
I think most Clojure developers will tell you that it is wise at first to just use Java libraries directly, if you can. Look at wrapper libraries to see how the author approached the Java interop, then do it yourself. You are more likely to attain something that is maintainable, flexible and appropriate for your individual style and needs than using what someone else built for the purpose of interop for their needs.
[deleted]
It does support hot-code reloading, the preeminent build tool for Clojurescript:
https://github.com/bhauman/lein-figwheel
has that out of the box. As for an actor model implementation, there is pulsar:
http://docs.paralleluniverse.co/pulsar/
Which has erlang-like actors, though some might suggest that core.async and its channel implementation provides everything you might need an actor for, YMMV.
https://github.com/bhauman/lein-figwheel
has that out of the box. As for an actor model implementation, there is pulsar:
http://docs.paralleluniverse.co/pulsar/
Which has erlang-like actors, though some might suggest that core.async and its channel implementation provides everything you might need an actor for, YMMV.
Hmm, I guess I better look deeper into Clojure. Finally I get to play with a Lisp.
My main interest with actors is that these can be made to support hot code reloading on the server side. They also tend to be easily composable. Also also, they can be optimized by locality (eg. same-node, same-cluster, different-cluster)
I'm biased though, having not worked with CSP or other models.
My main interest with actors is that these can be made to support hot code reloading on the server side. They also tend to be easily composable. Also also, they can be optimized by locality (eg. same-node, same-cluster, different-cluster)
I'm biased though, having not worked with CSP or other models.
I think you will find that as far as composability and hot code reloading, the combination of proper functional programming with a true REPL make this a powerful combination in Clojure that will at least match what you would get in a language built around actors.
For interactive Clojure/Script prototyping with Datomic, check out http://www.hyperfiddle.net/
> As an example I once ported an Elm project to Clojurescript and it was a 4x reduction in lines.
I'm curious to hear more about this. I'm someone who's used Elm at work, and on the side is interested in Lisp.
I'm curious to hear more about this. I'm someone who's used Elm at work, and on the side is interested in Lisp.
I think it is much easier to get real-world nontrivial work done in Clojurescript compared to Elm.
Can you go into any more specifics? I'm genuinely interested! Do you think it'll stay true as Elm matures?
Personally I think Elm is dying. It relies on a single language designer who works very very slowly. Since Elm came on the scene, vibrant languages with static typing for the front end have sprouted up and are better alternatives, like ReasonML if you want a language with static guarantees and workflow.
Elm could have been something, but I don’t expect it gain any mindshare, and the boat has sailed.
Clojurescript is a dynamic language, with easy JS interop and nearly zero boilerplate, so I still think it is the fastest route to a production app.
Elm could have been something, but I don’t expect it gain any mindshare, and the boat has sailed.
Clojurescript is a dynamic language, with easy JS interop and nearly zero boilerplate, so I still think it is the fastest route to a production app.
I write the server-side in Go, cross-compile to a Linux binary, and set that up as a service on a vanilla Ubuntu box (usually Digital Ocean). Deploying a new version is a matter of sftp'ing the new binary (and any templates, images, etc) over the top of the old one and restarting the service.
If I need a database then I use Postgres, and the setup for that can be a pain, so I get it documented/scripted using Ansible.
If I need something more complex than plain HTML on the client side then I use a Makefile to synchronise Webpack + Babel + React (and the hot reload during development), and the compiled bundle.js becomes another file to copy over.
I realise it's not very 2018, but to be honest I've kinda lost the will to live over learning anything more meta at this point.
If I need a database then I use Postgres, and the setup for that can be a pain, so I get it documented/scripted using Ansible.
If I need something more complex than plain HTML on the client side then I use a Makefile to synchronise Webpack + Babel + React (and the hot reload during development), and the compiled bundle.js becomes another file to copy over.
I realise it's not very 2018, but to be honest I've kinda lost the will to live over learning anything more meta at this point.
This is about as 2018 as it gets. Go and Rust are the only modern languages where you don't have to second-guess the stdlib for bad choices (looking at you php/ruby/javascript/etc..) yet provide amazing performance.
Backend: Go (optional embed db: ledisdb / boltdb / leveldb / rocksdb / etc...)
+
Frontend: create-react-app / create-react-native-app
Backend: Go (optional embed db: ledisdb / boltdb / leveldb / rocksdb / etc...)
+
Frontend: create-react-app / create-react-native-app
I find Ruby’s stdlib a pleasure to use.
How many web apps can you name that don’t rely on any external gems? Packaging that mess is a pain in every scripting language.
How far do you make it writing a web app in rust or go without pulling in external packages, then? Or a front-end using only javascript and html?
In Rust, it’s pretty quick. You could write a server yourself, but it would take a lot of work. It’s trivial with a package though.
Steve, what is Rust's equivalent to Go's cross-compilation-- plain old cargo build?
$ cargo build --target=TARGET
a list of default targets-- $ rustc --print target-list aarch64-linux-android aarch64-unknown-cloudabi aarch64-unknown-freebsd aarch64-unknown-fuchsia aarch64-unknown-linux-gnu aarch64-unknown-linux-musl arm-linux-androideabi arm-unknown-linux-gnueabi arm-unknown-linux-gnueabihf arm-unknown-linux-musleabi arm-unknown-linux-musleabihf armv4t-unknown-linux-gnueabi armv5te-unknown-linux-gnueabi armv7-linux-androideabi armv7-unknown-cloudabi-eabihf armv7-unknown-linux-gnueabihf armv7-unknown-linux-musleabihf asmjs-unknown-emscripten i586-pc-windows-msvc i586-unknown-linux-gnu i586-unknown-linux-musl i686-apple-darwin i686-linux-android i686-pc-windows-gnu i686-pc-windows-msvc i686-unknown-cloudabi i686-unknown-dragonfly i686-unknown-freebsd i686-unknown-haiku i686-unknown-linux-gnu i686-unknown-linux-musl i686-unknown-netbsd i686-unknown-openbsd mips-unknown-linux-gnu mips-unknown-linux-musl mips-unknown-linux-uclibc mips64-unknown-linux-gnuabi64 mips64el-unknown-linux-gnuabi64 mipsel-unknown-linux-gnu mipsel-unknown-linux-musl mipsel-unknown-linux-uclibc msp430-none-elf powerpc-unknown-linux-gnu powerpc-unknown-linux-gnuspe powerpc-unknown-netbsd powerpc64-unknown-linux-gnu powerpc64le-unknown-linux-gnu s390x-unknown-linux-gnu sparc-unknown-linux-gnu sparc64-unknown-linux-gnu sparc64-unknown-netbsd sparcv9-sun-solaris thumbv6m-none-eabi thumbv7em-none-eabi thumbv7em-none-eabihf thumbv7m-none-eabi wasm32-experimental-emscripten wasm32-unknown-emscripten wasm32-unknown-unknown x86_64-apple-darwin x86_64-linux-android x86_64-pc-windows-gnu x86_64-pc-windows-msvc x86_64-rumprun-netbsd x86_64-sun-solaris x86_64-unknown-bitrig x86_64-unknown-cloudabi x86_64-unknown-dragonfly x86_64-unknown-freebsd x86_64-unknown-fuchsia x86_64-unknown-haiku x86_64-unknown-l4re-uclibc x86_64-unknown-linux-gnu x86_64-unknown-linux-gnux32 x86_64-unknown-linux-musl x86_64-unknown-netbsd x86_64-unknown-openbsd x86_64-unknown-redox
a list of default targets-- $ rustc --print target-list aarch64-linux-android aarch64-unknown-cloudabi aarch64-unknown-freebsd aarch64-unknown-fuchsia aarch64-unknown-linux-gnu aarch64-unknown-linux-musl arm-linux-androideabi arm-unknown-linux-gnueabi arm-unknown-linux-gnueabihf arm-unknown-linux-musleabi arm-unknown-linux-musleabihf armv4t-unknown-linux-gnueabi armv5te-unknown-linux-gnueabi armv7-linux-androideabi armv7-unknown-cloudabi-eabihf armv7-unknown-linux-gnueabihf armv7-unknown-linux-musleabihf asmjs-unknown-emscripten i586-pc-windows-msvc i586-unknown-linux-gnu i586-unknown-linux-musl i686-apple-darwin i686-linux-android i686-pc-windows-gnu i686-pc-windows-msvc i686-unknown-cloudabi i686-unknown-dragonfly i686-unknown-freebsd i686-unknown-haiku i686-unknown-linux-gnu i686-unknown-linux-musl i686-unknown-netbsd i686-unknown-openbsd mips-unknown-linux-gnu mips-unknown-linux-musl mips-unknown-linux-uclibc mips64-unknown-linux-gnuabi64 mips64el-unknown-linux-gnuabi64 mipsel-unknown-linux-gnu mipsel-unknown-linux-musl mipsel-unknown-linux-uclibc msp430-none-elf powerpc-unknown-linux-gnu powerpc-unknown-linux-gnuspe powerpc-unknown-netbsd powerpc64-unknown-linux-gnu powerpc64le-unknown-linux-gnu s390x-unknown-linux-gnu sparc-unknown-linux-gnu sparc64-unknown-linux-gnu sparc64-unknown-netbsd sparcv9-sun-solaris thumbv6m-none-eabi thumbv7em-none-eabi thumbv7em-none-eabihf thumbv7m-none-eabi wasm32-experimental-emscripten wasm32-unknown-emscripten wasm32-unknown-unknown x86_64-apple-darwin x86_64-linux-android x86_64-pc-windows-gnu x86_64-pc-windows-msvc x86_64-rumprun-netbsd x86_64-sun-solaris x86_64-unknown-bitrig x86_64-unknown-cloudabi x86_64-unknown-dragonfly x86_64-unknown-freebsd x86_64-unknown-fuchsia x86_64-unknown-haiku x86_64-unknown-l4re-uclibc x86_64-unknown-linux-gnu x86_64-unknown-linux-gnux32 x86_64-unknown-linux-musl x86_64-unknown-netbsd x86_64-unknown-openbsd x86_64-unknown-redox
Thank you
Note that you also may want to use xargo or cargo-xbuild to build other custom targets, and rustup to fetch the stdlib for the targets listed above.
Aren't there also linker issues with cross-building for some targets like i686-pc-windows-msvc? At least, I don't think I ever got it to work properly but I don't recall what the exact problem was.
Some platforms are harder than others, it’s true. And if you link to any C code, you have to deal with that as well. As an example, I just saw this: http://zork.net/~st/jottings/rust-windows-and-debian.html
We’ll get there!
We’ll get there!
I never use server-side external packages when writing web apps (well, except the bcrypt crypto package, which is an official package but not technically part of the stdlib yet).
Dependencies are evil.
Dependencies are evil.
Anything that runs on JRuby can be packaged as a single file.
And even with MRI, it's not as painful as people make out. Set `$GEM_HOME`, `bundle install`, tar up your app and the gems, stick them on the server.
> as 2018 as it gets
sftp'ing a binary to your deploy target? That's more 2008 iyam...
sftp'ing a binary to your deploy target? That's more 2008 iyam...
How is this setting things up "quickly" when OP is asking to limit complexity? You're suggesting:
1. Server side in Go 2. Cross-compiling it 3. sftp'ing and restarting the service everytime 4. postgres 5. ansible 6. Makefiles 7. Webpack 8. Babel 9. React
1. Server side in Go 2. Cross-compiling it 3. sftp'ing and restarting the service everytime 4. postgres 5. ansible 6. Makefiles 7. Webpack 8. Babel 9. React
Writing web servers in Go is extremely easy. https://golang.org/doc/articles/wiki/
Cross-compiling with Go is done by setting two environment variables. That's it. This is not like the mess of C++ cross-compiling. In LiteIDE it is simply a matter of choosing Linux from a drop-down: https://www.wut.de/pics/screenshot/e-505ww-07-pide-000.png
SFTP is not exactly hard. Nor is `nohup ./server &`.
From 5 on I agree though - is that 4 build systems? Insanity. I would just make a static web page with normal HTML forms or whatever and Go templates. If you really need client-side Javascript, I'd just use jQuery, or something similar and lightweight like minifiedjs.
Cross-compiling with Go is done by setting two environment variables. That's it. This is not like the mess of C++ cross-compiling. In LiteIDE it is simply a matter of choosing Linux from a drop-down: https://www.wut.de/pics/screenshot/e-505ww-07-pide-000.png
SFTP is not exactly hard. Nor is `nohup ./server &`.
From 5 on I agree though - is that 4 build systems? Insanity. I would just make a static web page with normal HTML forms or whatever and Go templates. If you really need client-side Javascript, I'd just use jQuery, or something similar and lightweight like minifiedjs.
yeah, I use straight HTML wherever possible. But for some things it isn't possible, or suitable. I'd love a simpler client-side environment. Any suggestions welcome... I'm looking at Vue.js now, recommended from comments here.
I've enjoyed using Elm for client side development.
I second this; Go + React.js (Vue.js in my case)
I talked about it just a couple of hours ago [1].
[1] https://news.ycombinator.com/item?id=17215658
I talked about it just a couple of hours ago [1].
[1] https://news.ycombinator.com/item?id=17215658
That's interesting... I think I'll spend a couple of days playing with Vue to see if I can get rid of Webpack and Babel, because they're an enormous pain to set up (especially as they keep changing their config schema every major version release - I think I've climbed Webpack's config learning cliff three times now).
I try dozen of tools for a cross-platform app and finally settle on use vue.
Every time I use node and look at his insanity and get depressed.
So, I dislike STRONGLY the use of Webpack and friends. Is a chore because JS is even more nuts now, and everything assume you want node nonsense everywhere.
So, I persist and do this:
I introduce:
> Non non-sense javascript front-end setup with vue
https://gist.github.com/mamcx/1d3aa692b0d34b0fae696c12292a1a...
Using local .js/.css files downloaded from a cdn, then using cat to concat in the correct order all the deps, and finally let to build your css/js as you please for your logic.
Build time is zero after the first try.
P.D: Maybe using unix pipes I could minimify and stuff like that, but I don't need that.
Every time I use node and look at his insanity and get depressed.
So, I dislike STRONGLY the use of Webpack and friends. Is a chore because JS is even more nuts now, and everything assume you want node nonsense everywhere.
So, I persist and do this:
I introduce:
> Non non-sense javascript front-end setup with vue
https://gist.github.com/mamcx/1d3aa692b0d34b0fae696c12292a1a...
Using local .js/.css files downloaded from a cdn, then using cat to concat in the correct order all the deps, and finally let to build your css/js as you please for your logic.
Build time is zero after the first try.
P.D: Maybe using unix pipes I could minimify and stuff like that, but I don't need that.
Vue apps depends on webpack as well.
But the vue-cli makes the whole set up a breeze. Especially v3 (currently in beta)
If the website you're building is simple you could even have vanilla html pages then attach vue to the divs that need that extra interactivity, then you won't any fancy loaders.
If the website you're building is simple you could even have vanilla html pages then attach vue to the divs that need that extra interactivity, then you won't any fancy loaders.
React doesn't need webpack or babel. People just see lots of benefit in using them, but there are tutorials out there on how to use just React.
It can be as simple as a script tag at the bottom of your html and then writing ES5 React.
It can be as simple as a script tag at the bottom of your html and then writing ES5 React.
If you just have a Vue file script tag in your document, you're good to go. If you want single file components, hot module reloading, Babel features, etc, you'll need Webpack. Luckily, the current and beta versions of the vue-cli make these non-existant problems. Just install using the cli and it's good to go, no setup needed.
How do you handle server side rendering? This is one of the reasons I chose to go full Node+React.
Check out gatsbyjs.org for server side react rendering.
nuxt.js is an all in one vue framework that has ssr and a really cool file based routing functionality
Vue also has server side rendering.
Look up express-vue
Your start is good but you add complexity on top of it. Install Golang on your VPS, clone the source code on it and compile it there instead of messing with cross compilation.
Also use sqlite to avoid the pain of setting up a SQL server, there is no need for it.
You can then easily get systemd to supervise your binary.
This is how I host all my web apps, the main difference is that I don't use Go but Nim. If you want a great framework match up then check out Jester + Karax, see how I developed the Nim Forum using this combination.
Also use sqlite to avoid the pain of setting up a SQL server, there is no need for it.
You can then easily get systemd to supervise your binary.
This is how I host all my web apps, the main difference is that I don't use Go but Nim. If you want a great framework match up then check out Jester + Karax, see how I developed the Nim Forum using this combination.
> instead of messing with cross compilation.
To be fair, cross-compilation in Go is as simple as setting and environment variable.
To be fair, cross-compilation in Go is as simple as setting and environment variable.
And what about zero downtime deploy (upgrading the app binary and updating the database schema)? It's difficult to do without some kind of reverse proxy and without a database server.
How often is that really required? OP asked for a quick deploy, for most apps it's enough to put the db into read-only mode and then update the schema. Upgrading the app binary is as simple as replacing it on the file system and then restarting the service.
The more often we deploy with CI/CD, the more we need zero downtime deploy. Putting the DB in read-only mode is not that simple, because the app needs to be able to work in a degraded read-only mode.
Yeah DB migrations are a pain in the bum. I do them manually because I still haven't found a tool that handles them properly.
But by the time there's significant data to migrate to the new schema, any schema change is usually due to a major version change or feature implementation, and the migration is part of a wider pain-in-the-bum situation.
But by the time there's significant data to migrate to the new schema, any schema change is usually due to a major version change or feature implementation, and the migration is part of a wider pain-in-the-bum situation.
Better would be to just use docker.
Please explain. I still don't understand the use-case for docker...
How is docker going to make my life easier in this example?
How is docker going to make my life easier in this example?
For me this is the response to 'how do you build stable/scaleable/.../good web apps in 2018', but sadly not to 'favorite way of getting a web app up quickly in 2018?'.
The whole process of starting a new VM for every little project seems to me like overkill and developing components if you just want to get a prototype out the door can be difficult as the components will most likely have such a poor quality that you can't reuse them for anything else.
With that said, I am 100% pro Golang Server + Vue.js UI when it comes to building something which will be definitely more than a prototype (no shortcuts taken).
The whole process of starting a new VM for every little project seems to me like overkill and developing components if you just want to get a prototype out the door can be difficult as the components will most likely have such a poor quality that you can't reuse them for anything else.
With that said, I am 100% pro Golang Server + Vue.js UI when it comes to building something which will be definitely more than a prototype (no shortcuts taken).
whats the level of your app's complexity?
Your description would seem good for something management etc has down on paper / a design document.
Your description would seem good for something management etc has down on paper / a design document.
How is it possible that you sftp the new binary while the sever is running?
It won’t let you because the file is in use.
Unlike windows, Linux allows you to delete a binary while it's running (the binary file is not locked).
Windows allows you to rename it.
%s/react/vuejs/
Heroku and Heroku Addons are freely available at my company, so it’s the preferred deployment target. I work on a developer productivity team so being able to stamp out apps fast is one of our most important requirements.
Heroku has given us a ton of flexibility, and with that we’ve been able to become very opinionated and standardize on one stack. 12 factor design patterns (and the opinions of Django-cookiecutter) allowed us to stop arguing about how to do something and just get it done.
We use GitHub for source control and Heroku Pipelines for CI and testing. Every push runs functional tests, every PR spins up a “review app” with full dependencies and test data.
Heroku Postgres is our system of record database. Postgres is stable, fast, and full featured. With jsonb fields we’re able to store complex structured build log data and quickly aggregate on it. Heroku Data Clips are super useful for quick reviews of the data without building a report into an app.
Heroku Redis and S3 are the only other data stores. S3 stores build results and end user assets, and Redis handles anything in memory. We use Brandur’s transactionally drained job queue pattern (https://brandur.org/job-drain) to defer tasks.
The apps currently all render to plain ol HTML and for the most part take a document centric approach to front end. Additionally, our apps are all API first and we use CoreAPI to create CLI clients automatically. Those are usually our administration tools which help make sure we are API complete.
Heroku has given us a ton of flexibility, and with that we’ve been able to become very opinionated and standardize on one stack. 12 factor design patterns (and the opinions of Django-cookiecutter) allowed us to stop arguing about how to do something and just get it done.
We use GitHub for source control and Heroku Pipelines for CI and testing. Every push runs functional tests, every PR spins up a “review app” with full dependencies and test data.
Heroku Postgres is our system of record database. Postgres is stable, fast, and full featured. With jsonb fields we’re able to store complex structured build log data and quickly aggregate on it. Heroku Data Clips are super useful for quick reviews of the data without building a report into an app.
Heroku Redis and S3 are the only other data stores. S3 stores build results and end user assets, and Redis handles anything in memory. We use Brandur’s transactionally drained job queue pattern (https://brandur.org/job-drain) to defer tasks.
The apps currently all render to plain ol HTML and for the most part take a document centric approach to front end. Additionally, our apps are all API first and we use CoreAPI to create CLI clients automatically. Those are usually our administration tools which help make sure we are API complete.
I'll chime in on the pro-CI discussion and leave the language discussions to "what's the best front end lang" posts.
I just got done revamping my decade-old PHP experience to full OO, and really upped productivity with the Slim framework to build a REST API for our app. I'm using Salesforce platform as the database backend, which is slow but I encapsulate all the business logic there. That's all cool, but, it didn't seem like I was hitting the mainstream of productivity.
Long story short, I'm on the Google/TypeScript/Material/Node bandwagon now. The dev environment is easy, and there's a wide choice of Node deployment platforms. I believe we can get the kind of deployment productivity we want with using a CI pipeline based on Github or Bitbucket that squirts commits to Google App Engine.
I just got done revamping my decade-old PHP experience to full OO, and really upped productivity with the Slim framework to build a REST API for our app. I'm using Salesforce platform as the database backend, which is slow but I encapsulate all the business logic there. That's all cool, but, it didn't seem like I was hitting the mainstream of productivity.
Long story short, I'm on the Google/TypeScript/Material/Node bandwagon now. The dev environment is easy, and there's a wide choice of Node deployment platforms. I believe we can get the kind of deployment productivity we want with using a CI pipeline based on Github or Bitbucket that squirts commits to Google App Engine.
Oh man, do I love this question.
For the stack, Ruby on Rails with React.
But my secret sauce is the DevOps:
+ GitLab
+ GitLab CI
+ Heroku
+ Git + Git tags
I also add some magic npm scripts to take care of semver tagging. And with my build:
+ All pushes are tested
+ All changes to master are tested and deployed to staging
+ All semver tagged commits are tested and deployed to production
+ Also, all database migrations happen automatically.
I documented my entire process by building and deploying a sample app here: https://www.toptal.com/devops/effective-ci-cd-deployment-pip...
For the stack, Ruby on Rails with React.
But my secret sauce is the DevOps:
+ GitLab
+ GitLab CI
+ Heroku
+ Git + Git tags
I also add some magic npm scripts to take care of semver tagging. And with my build:
+ All pushes are tested
+ All changes to master are tested and deployed to staging
+ All semver tagged commits are tested and deployed to production
+ Also, all database migrations happen automatically.
I documented my entire process by building and deploying a sample app here: https://www.toptal.com/devops/effective-ci-cd-deployment-pip...
Can you give me a resource to get started with devops. I have only heard these ideas, but don't have any clue why at all they are required.
The idea is to automate repetitive tasks as much as you can because doing them by hand takes time and is error-prone. Build, deployment and testing are tasks that are well suited to automation.
This!
I started by automating things that would take too long. At first it was taking code from my repository and deploying it to Heroku. Then I discovered that CI services literally gave you servers to run scripts on to interact with your code after a git push, so I started running tests in these servers.
Fast forward a few years and I automated everything except writing and maintaining the codebase.
I even run linting tests in CI so no badly written code can even make it to code review.
I started by automating things that would take too long. At first it was taking code from my repository and deploying it to Heroku. Then I discovered that CI services literally gave you servers to run scripts on to interact with your code after a git push, so I started running tests in these servers.
Fast forward a few years and I automated everything except writing and maintaining the codebase.
I even run linting tests in CI so no badly written code can even make it to code review.
Django web app deployed to Heroku is the fastest way I know of right now.
Django because that's what I know best. I can code a basic CRUD app (which is basically 90% of all apps I have ever needed to build) in a few hours.
Heroku because a simple procfile and push to a git remote is all that's needed to launch the application.
I think the best piece of advice I would give is to use whatever you're most comfortable with. If you use a new technology that saves you 50% on deployment time, but adds days to the time you need for actual development because you are unfamiliar with it, is not worth it in my opinion.
Deployment/setup takes maybe an hour or 2 for the kinds of basic app I think you're talking about. Development is easily days or weeks. Optimizing deployment over development is optimizing the wrong thing in my opinion.
Django because that's what I know best. I can code a basic CRUD app (which is basically 90% of all apps I have ever needed to build) in a few hours.
Heroku because a simple procfile and push to a git remote is all that's needed to launch the application.
I think the best piece of advice I would give is to use whatever you're most comfortable with. If you use a new technology that saves you 50% on deployment time, but adds days to the time you need for actual development because you are unfamiliar with it, is not worth it in my opinion.
Deployment/setup takes maybe an hour or 2 for the kinds of basic app I think you're talking about. Development is easily days or weeks. Optimizing deployment over development is optimizing the wrong thing in my opinion.
I use Swagger/OpenAPI to define the REST API, which is fast and makes the API including the main data types easily visible.
To implement the server side I typically generate Java JAX-RS skeleton code that can run in Jetty using Swagger codegen. You fill out implementation code and the app is off and running.
On the client side I generate Angular client stubs using Swagger codegen, then fill build services and UI components on top. For CLIs or other tools you can take a similar approach or just write the REST calls directly.
Code generation from an OpenAPI spec makes this process a lot quicker as it takes care of most of the boilerplate code necessary to process REST requests. It's especially helpful for making quick changes and also helps you to get to a stable, easily understandable API which is necessary if you decide to turn the service(s) into a real product.
Docker is incidentally a godsend for systems with multiple services, especially if you work in polyglot environments.
To implement the server side I typically generate Java JAX-RS skeleton code that can run in Jetty using Swagger codegen. You fill out implementation code and the app is off and running.
On the client side I generate Angular client stubs using Swagger codegen, then fill build services and UI components on top. For CLIs or other tools you can take a similar approach or just write the REST calls directly.
Code generation from an OpenAPI spec makes this process a lot quicker as it takes care of most of the boilerplate code necessary to process REST requests. It's especially helpful for making quick changes and also helps you to get to a stable, easily understandable API which is necessary if you decide to turn the service(s) into a real product.
Docker is incidentally a godsend for systems with multiple services, especially if you work in polyglot environments.
If you need to build an API quickly we just launched https://code.xyz on Thursday. No server provisioning, no routing, nada, just write a JavaScript function, hit deploy, and you have a scalable "serverless" backend. You can deliver any type of content. (We have command line tools available as well, if the web environment doesn't suit all your needs.)
Our company is called StdLib, we're focused on making API development, deployment and management effortless - we're backed by both Slack and Stripe [1].
[1] https://stdlib.com/blog/stripe-code-xyz/
Our company is called StdLib, we're focused on making API development, deployment and management effortless - we're backed by both Slack and Stripe [1].
[1] https://stdlib.com/blog/stripe-code-xyz/
Wow, really neat. I guess you're working on top of AWS lambda or something? If so, how do you get around the 75 gig code size limit? Just "That will be a good problem to have when we have all those customers"?
Rails + heroku is pretty much instant. If you want to pay a little little less a single vps instance can run the web app and the postgres server at the same time.
With a single VPS, you're missing the DB backup that is probably the most important piece if the puzzle provided by heroku.
Depends on the DB size. For small side projects I do weekly SQL dumps, 7-zip them, and email as attachments to my GMail, where they get automatically tagged and marked as read.
This guy hacks.
Consider using one of the command line tools to upload directly to your google drive. Have a script to do the zipping and calling the gdrive app on the zipped file, and run that as a cron job.
Don't want to be too off-topic, but I do wonder how that jibes with GDPR. I guess if they are encrypted it should be fine.
Whichever process you use is fine, but I wanted to highlight that there is more to heroku than just deploying your apps.
Yes, heroku's hosted postgres is fantastic. Once you have users you should use that, or aws rds, or learn how to do it properly yourself. Until then a cron job to backup your db every week, or day or every 12 hours or whatever is good enough.
I use Elixir/Phoenix mainly because I think it is fun and think that side projects should be fun. If it has the potential to become something more, I believe that it is a great production language for a company and would stake my business on it. Usually deploy to Heroku free tier for my up and fast prototypes.
Frontend will either be React or plain ol' JS depending on how complex the idea is.
Frontend will either be React or plain ol' JS depending on how complex the idea is.
Coming from nodejs, phoenix is incredible. Out of the box, phoenix just uses nodejs to generate all your frontend assets, and channels are incredibly easy to use. I'm still learning about how elixir works under the covers, but so far I'm really impressed.
How much learning curve if One doesn't know Erlang to get speed up in phoenix?
You don't really need to know Erlang.
Elixir is like if Erlang and Ruby had a child. It's a functional languages, so I guess there's a bit of a curve there. Plus you get stuff like macros, which are incredible, but I thought was some kind of voodoo magic the first time I encountered them.
There's a pretty decent tutorial on the elixir site, and the phoenix site if you want to learn.
As for the learning curve, I didn't struggle with it for very long at all, but your results may vary.
https://elixir-lang.org/getting-started/introduction.html
https://hexdocs.pm/phoenix/overview.html
Elixir is like if Erlang and Ruby had a child. It's a functional languages, so I guess there's a bit of a curve there. Plus you get stuff like macros, which are incredible, but I thought was some kind of voodoo magic the first time I encountered them.
There's a pretty decent tutorial on the elixir site, and the phoenix site if you want to learn.
As for the learning curve, I didn't struggle with it for very long at all, but your results may vary.
https://elixir-lang.org/getting-started/introduction.html
https://hexdocs.pm/phoenix/overview.html
These are two separate things: Erlang and Elixir are one, Phoenix is another.
In general, you don't need to know any Erlang to start working with Elixir. In time, as you advance your knowledge and start looking at more advanced features, you'll need the ability to read Erlang at some point, but that's actually pretty trivial: Erlang syntax is one of the simplest/smallest out there. It's much better in this case than it's with Clojure and Java.
The functional nature of Elixir may be a little weird, but, if you're worried about this, it's not taken to the extreme like in Haskell. At the end of the day, you do have a process dictionary (don't use it), and normal IO. It's true for both Erlang and Elixir, but Elixir adds some improvements on top of that: in Elixir, you can re-bind a variable (Erlang has single assignment only), you get the familiar syntax for accessing elements of collections (`coll[:keyname]`), the `if` is "fixed" to be normal if-then-else (the usual Erlang construct is dubbed `cond` in Elixir) and so on. It's FP but in the spirit of OCaml rather than Haskell: pragmatic and striving to be convenient without pulling the users' minds through a monad.
Now, Phoenix is another thing altogether. As far as frameworks go, Phoenix is very well designed, with a couple of orthogonal concepts being composed into a highly functional whole. To be honest, I didn't use Phoenix yet, personally - I did some code review for colleagues, but my own projects are written with Plug for now. Plug is a library which is comparable to WSGI spec in Python plus some additional utils, like in Werkzeug. Phoenix is built on top of Plug, so I figured learning it first is not a bad idea.
Turns out you can get by with Plug (and eventually some "plugs" packages from other people) for quite a while; the experience is like with Flask or Sinatra. You have to know what you want, exactly, but if you do, it's trivial to build a basic framework out of the available plugs. It's actually a strong selling point of the whole tech: as I mentioned, Plug is as much a library as a specification (with the same motivation as WSGI) and it's great for interoperability of components. The whole stack is composable and extensible at the same time, which is not that easy to pull off as far as framework designs go.
Documentation is decent, although its searchability is less so, I had a good time with devdocs.io for the core language and with hexdocs for plugs. It's definitely grokkable, and I'd say worth a try.
In general, you don't need to know any Erlang to start working with Elixir. In time, as you advance your knowledge and start looking at more advanced features, you'll need the ability to read Erlang at some point, but that's actually pretty trivial: Erlang syntax is one of the simplest/smallest out there. It's much better in this case than it's with Clojure and Java.
The functional nature of Elixir may be a little weird, but, if you're worried about this, it's not taken to the extreme like in Haskell. At the end of the day, you do have a process dictionary (don't use it), and normal IO. It's true for both Erlang and Elixir, but Elixir adds some improvements on top of that: in Elixir, you can re-bind a variable (Erlang has single assignment only), you get the familiar syntax for accessing elements of collections (`coll[:keyname]`), the `if` is "fixed" to be normal if-then-else (the usual Erlang construct is dubbed `cond` in Elixir) and so on. It's FP but in the spirit of OCaml rather than Haskell: pragmatic and striving to be convenient without pulling the users' minds through a monad.
Now, Phoenix is another thing altogether. As far as frameworks go, Phoenix is very well designed, with a couple of orthogonal concepts being composed into a highly functional whole. To be honest, I didn't use Phoenix yet, personally - I did some code review for colleagues, but my own projects are written with Plug for now. Plug is a library which is comparable to WSGI spec in Python plus some additional utils, like in Werkzeug. Phoenix is built on top of Plug, so I figured learning it first is not a bad idea.
Turns out you can get by with Plug (and eventually some "plugs" packages from other people) for quite a while; the experience is like with Flask or Sinatra. You have to know what you want, exactly, but if you do, it's trivial to build a basic framework out of the available plugs. It's actually a strong selling point of the whole tech: as I mentioned, Plug is as much a library as a specification (with the same motivation as WSGI) and it's great for interoperability of components. The whole stack is composable and extensible at the same time, which is not that easy to pull off as far as framework designs go.
Documentation is decent, although its searchability is less so, I had a good time with devdocs.io for the core language and with hexdocs for plugs. It's definitely grokkable, and I'd say worth a try.
The biggest things you'd need to know is that Erlang does exist under the covers and you'll start spotting where it peaks through.
Once deployed, the best material on running beam apps is for Erlang, as well as ops tools like recon, and so you'll start learning and using it more then.
Once deployed, the best material on running beam apps is for Erlang, as well as ops tools like recon, and so you'll start learning and using it more then.
A year ago I would say Flask + Firebase, but now I have began to understand that that is the quickest way to build a web app FOR ME.
The best tech stack is the one that gets the job done FOR YOU, in the least amount of time. If it takes me 4 weeks to learn some arbitrary <INSERT NOUN HERE>.js framework to then be able to do stuff "quickly" then it better cut down development time by atleast +4 weeks to be worth it. No doubt, some amount of Yak shaving is worth it for the future (when you already have acquired a skill and no longer need to spend time learning) but in a scenario where speed of dev is important, go for technologies that you know and are comfortable with (which differs from person to person)
Only general piece of advice I would give is to use SaaS tools to do heavy lifting. Tools like Auth0, Firebase Cloud Functions and authorization, etc can save you quite a bit of time compared to the learning curve they come with. Not to mention these products have teams behind them who work round the clock to make them developer friendly, so if you can't understand and get them running quick enough then IMO the tool is flawed not the user.
The best tech stack is the one that gets the job done FOR YOU, in the least amount of time. If it takes me 4 weeks to learn some arbitrary <INSERT NOUN HERE>.js framework to then be able to do stuff "quickly" then it better cut down development time by atleast +4 weeks to be worth it. No doubt, some amount of Yak shaving is worth it for the future (when you already have acquired a skill and no longer need to spend time learning) but in a scenario where speed of dev is important, go for technologies that you know and are comfortable with (which differs from person to person)
Only general piece of advice I would give is to use SaaS tools to do heavy lifting. Tools like Auth0, Firebase Cloud Functions and authorization, etc can save you quite a bit of time compared to the learning curve they come with. Not to mention these products have teams behind them who work round the clock to make them developer friendly, so if you can't understand and get them running quick enough then IMO the tool is flawed not the user.
Here's my template:
Backend in Go, hosted on Gitlab with CI to build it and create a docker image (also hosted at Gitlab).
Server is a plain Debian server hosted on Digital Ocean, with some light configuration with Ansible. A single docker-compose.yml brings up the application along with any service dependencies. Generally I use nginx-proxy with its letsencrypt companion so I can multiplex several docker web services and do SSL termination, all from within the docker-compose file.
Frontend in angular, react, or react native.
This is easy, automated, cheap, and not too exotic. I can host multiple things on a single server if I want, but easily splice them off to their own server later.
Backend in Go, hosted on Gitlab with CI to build it and create a docker image (also hosted at Gitlab).
Server is a plain Debian server hosted on Digital Ocean, with some light configuration with Ansible. A single docker-compose.yml brings up the application along with any service dependencies. Generally I use nginx-proxy with its letsencrypt companion so I can multiplex several docker web services and do SSL termination, all from within the docker-compose file.
Frontend in angular, react, or react native.
This is easy, automated, cheap, and not too exotic. I can host multiple things on a single server if I want, but easily splice them off to their own server later.
This sounds a lot like what I'm looking for. I haven't looked into Gitlab at all yet, so I'll to check them out.
GitLab has been a pain for me lately.
Chose them for a client due to built-in CI (as opposed to Github), but the HTTP response time on the web UI makes it painful to use - I'm routinely seeing ~1s response times on pull requests and CI pipelines, not to mention that the provided CI "runners" seem overloaded and your jobs often stay in a pending stage for several minutes (can be solved by running your own instance of gitlab-runner on an AWS box).
Personally I'm moving that project to Bitbucket - they now have CI pipelines too.
Chose them for a client due to built-in CI (as opposed to Github), but the HTTP response time on the web UI makes it painful to use - I'm routinely seeing ~1s response times on pull requests and CI pipelines, not to mention that the provided CI "runners" seem overloaded and your jobs often stay in a pending stage for several minutes (can be solved by running your own instance of gitlab-runner on an AWS box).
Personally I'm moving that project to Bitbucket - they now have CI pipelines too.
Not having a server at all is the easiest. I run my front ends on S3 / CloudFront. Backend is run on Lambdas, with state stored in DynamoDB/SimpleDB (can't wait for serverless Aurora though!).
create-react-app and aws-amplify gets you really far in a hurry.
I then normally use react-redux, @redux-offline/redux-offline, react-router-dom, and flow-bin.
Examples: - https://gitlab.com/kabo/synchronize-swatches - https://gitlab.com/kabo/hydrant-map - https://gitlab.com/kabo/cryptodo
For more backendy stuff I use serverless to manage lambdas.
Easy as :)
create-react-app and aws-amplify gets you really far in a hurry.
I then normally use react-redux, @redux-offline/redux-offline, react-router-dom, and flow-bin.
Examples: - https://gitlab.com/kabo/synchronize-swatches - https://gitlab.com/kabo/hydrant-map - https://gitlab.com/kabo/cryptodo
For more backendy stuff I use serverless to manage lambdas.
Easy as :)
as a frontend dev new to this stuff - how do you keep your lambdas secure? literally anyone can see your secrets?
I'm gonna go through your code, thanks for sharing, just wanted to ask in case you have a big picture insight about how serverless auth/security is best done. this stuff freaks me out because i know nothing about it.
I'm gonna go through your code, thanks for sharing, just wanted to ask in case you have a big picture insight about how serverless auth/security is best done. this stuff freaks me out because i know nothing about it.
I'm afraid I don't follow. What secrets are you referring to? Secrets in the code running on the lambda can't be seen by anyone. If you mean secrets to invoke the lambda I usually have lambdas be completely open (no auth required) or have users log in with cognito and use aws-sdk invoke the lambda, which takes care of auth for me.
Google app engine is my go to for web apps that need to be used in production at a small scale while I'm still evolving the functionality. What you prototype transfers into prod surprisingly well. The best part is I don't really have to worry about security - I just setup one of the default available authentication types and define access control in the routes in app.yaml. You don't have to be worried a hacking group will somehow subvert your instance if you miss applying a security update or mess up firewalls etc. If it's an internal app and your company is using Google Apps for business, you can even restrict access to people logged in to the company domain very easily.
The persistence layer is a bit problematic at very small scale (think hobby projects) but if you are willing to spin up a cloud SQL instance which wouldn't be an issue for paid projects, you get an excellent secure auto managed environment.
The persistence layer is a bit problematic at very small scale (think hobby projects) but if you are willing to spin up a cloud SQL instance which wouldn't be an issue for paid projects, you get an excellent secure auto managed environment.
What do you find problematic about Cloud Datastore for small-scale projects?
I work on an open source implementation of it, so I'm always curious to hear about use cases and opinions.
I work on an open source implementation of it, so I'm always curious to hear about use cases and opinions.
Basically the lack of straight SQL support. "SQL-Like" means you end up calling their custom API functions and having to understand its unique API semantics in sufficient depth to build your persistence layer. Life would be so much simpler if it simply supported a subset of SQL - ideally with a standard interface like the Go's SQL.
The quickest thing to develop in is normally what you know. I find django the most productive web framework for things that might take off (for purely static sites I use Hugo and serve the site from S3, and deploy it using cloudformation - a great combo that lets me bring up a landing page in an hour or so).
It sounds like deployment is what you want to simplify. While there is extra overhead in learning to use docker, deployment is one of the major issues it solves. I spent a day or two learning docker and docker compose, and now I have a local dev environment I can work in, and I'll be able to deploy to a host quite simply. Makefiles are an excellent, simple companion to docker, so it's also worth learning them.
The big benefit of this is that you abstract your code from how to run it. So today you might like django, tomorrow ruby/language du jour, but all of that would still be built as a docker container which you'd be able to deploy to the same host with minor modifications.
Also, to set up user accounts, create storage buckets, etc check out terraform. The language it uses, HCL, is a trainwreck if you need conditionals, but apart from that it works well and is simple (too simple, that's the trouble). So a combination of:
* whatever web framework you're productive with
* built into a docker container
* with makefiles to ease administrative tasks
* terraform to configure a cloud backend
is a very powerful combination. But yeah, more stuff to learn. At least this approach means you can swap out the web framework for any other language and nothing else really needs to change.
It sounds like deployment is what you want to simplify. While there is extra overhead in learning to use docker, deployment is one of the major issues it solves. I spent a day or two learning docker and docker compose, and now I have a local dev environment I can work in, and I'll be able to deploy to a host quite simply. Makefiles are an excellent, simple companion to docker, so it's also worth learning them.
The big benefit of this is that you abstract your code from how to run it. So today you might like django, tomorrow ruby/language du jour, but all of that would still be built as a docker container which you'd be able to deploy to the same host with minor modifications.
Also, to set up user accounts, create storage buckets, etc check out terraform. The language it uses, HCL, is a trainwreck if you need conditionals, but apart from that it works well and is simple (too simple, that's the trouble). So a combination of:
* whatever web framework you're productive with
* built into a docker container
* with makefiles to ease administrative tasks
* terraform to configure a cloud backend
is a very powerful combination. But yeah, more stuff to learn. At least this approach means you can swap out the web framework for any other language and nothing else really needs to change.
This is a quite a bit in-line with my thinking. Probably best to go ahead and spend a little time figuring out Docker (and the best way of using it with some hosting service... I'll check out terraform).
I'm surprised nobody is talking about Express for the back end. Maybe it's because I hail from the front end world, but I'm already so comfortable in javascript I'm faster in it than if I had to learn anything else.
For the front end, I like Vue because it's just react with less boilerplate.
For the front end, I like Vue because it's just react with less boilerplate.
It blows my mind that there still isn't a polished ORM for the node.js / Express ecosystem.
Precisely this. I came from the Django world to try starting a Node.js project, and was absolutely blown away by how immature ORMs and even database libraries felt. In Python, you have SQLalchemy and Django ORM, both of which are fantastic and make ample use of the language. But for JavaScript, it felt like an uphill battle, especially if you want to do anything fancy.
Of course you don't _need_ an ORM or at least you definitely don't need one as full-blown as Django ORM. But I didn't even feel comfortable using any of the solutions I saw that were supposedly the 'best.' And yet, when I went and evaluated the solutions, I do agree they were the best - I just never felt like they were mature enough to really use yet. As far as not using an ORM goes, certainly this is doable, but at the end of the day if you don't want to hardcode a bunch of SQL queries and statements you probably are going to need to write code that will begin to look awfully like ORM code for basic operations...
Of course you don't _need_ an ORM or at least you definitely don't need one as full-blown as Django ORM. But I didn't even feel comfortable using any of the solutions I saw that were supposedly the 'best.' And yet, when I went and evaluated the solutions, I do agree they were the best - I just never felt like they were mature enough to really use yet. As far as not using an ORM goes, certainly this is doable, but at the end of the day if you don't want to hardcode a bunch of SQL queries and statements you probably are going to need to write code that will begin to look awfully like ORM code for basic operations...
Most Python libraries are a lot more mature than NodeJS libraries. This makes sense because they are also often a lot older. That being said, all ecosystems have their up- and downsides. Fpr example, I think package management for NodeJS is infinite amount of times better than for Python. Pipenv only came around one year or so ago.
Datastore Agnostic:
- JS-Data - https://github.com/js-data/js-data
SQL:
- Sequelize - https://github.com/sequelize/sequelize
- Bookshelf - https://github.com/bookshelf/bookshelf
- Objection - https://github.com/Vincit/objection.js
- TypeORM - https://github.com/typeorm/typeorm
NoSQL:
- Mongoose - https://github.com/Automattic/mongoose
- Thinky - https://github.com/neumino/thinky
- JS-Data - https://github.com/js-data/js-data
SQL:
- Sequelize - https://github.com/sequelize/sequelize
- Bookshelf - https://github.com/bookshelf/bookshelf
- Objection - https://github.com/Vincit/objection.js
- TypeORM - https://github.com/typeorm/typeorm
NoSQL:
- Mongoose - https://github.com/Automattic/mongoose
- Thinky - https://github.com/neumino/thinky
All those listed in the SQL category (the category almost everyone actually cares about) are total crap compared to, for example, ActiveRecord. GP said polished not plentiful.
Have personal experience with Sequelize and TypeORM, both are very far from being polished and finished.
> ORM for the node.js / Express ecosystem
Coming from Python world, it's probably for the best that nobody is using ORMs.
Coming from Python world, it's probably for the best that nobody is using ORMs.
Can you expand on your logic here? Is this because Python ORMs have gotten too bloated?
They are bloated and they are not performant. If you are using Node and the main benefit of node is its asynchronous execution flow you would be shooting yourself in the foot by using an ORM and gaining all the overhead that comes from serialization and deserialization.
Your comment reeks of inexperience.
Haha, your comment reeks of inexperience. The thing you have namely not experienced is the pain of having to port an entire service to a different language because SQLAlchemy is as slow as a snail.
But yes, keep on using your ORMs because using a query builder is too hard. I'm sure your significant experience building services that will at most ever handle 2 QPS is very important to the software engineering world.
But yes, keep on using your ORMs because using a query builder is too hard. I'm sure your significant experience building services that will at most ever handle 2 QPS is very important to the software engineering world.
For what it's worth, if SQLAlchemy (or any other ORM) is slow, it's probably not because of "serialization" and "deserialization" (of whatever you had in mind), but because the database is queried in a (really, really) inefficient way.
It's also unclear how that's related to whether you're working in an async environment or not.
He was probably thinking about stuff like that.
It's also unclear how that's related to whether you're working in an async environment or not.
He was probably thinking about stuff like that.
One of the biggest bottlenecks for us was creating these massive nested Python objects.
Typeorm has been fantastic for me: https://github.com/typeorm/typeorm
It strikes just the right balance between the data modeling approach and query building for me.
It strikes just the right balance between the data modeling approach and query building for me.
Have a look at http://loopback.io
Express with scaffolding and connectors to memory, MongoDb, MySql, MsSql and other.
Maybe check out the one we built in the Qbix Platform. It does tons of stuff including sharding and autogenerating model code for you:
https://github.com/Qbix/Platform/blob/master/platform/classe...
https://github.com/Qbix/Platform/blob/master/platform/classe...
https://github.com/Qbix/Platform/blob/master/platform/classe...
https://github.com/Qbix/Platform/blob/master/platform/classe...
There are multiple. Sequelize is the best and I've used it in a few projects
Everyone complains about ActiveRecord, but other ecosystems often have far worse options to choose from than AR and Sequel.
Rails still rocks, ruby is still beautiful and elegant, Heroku is still incredibly easy to deploy to. Vuejs is a good option for complex data driven ui.
This is my go-to as well, incredibly easy and fast to get going but also scales reasonably well.
The only caveat I’d say is I prefer Roda over Rails for APIs and simple projects.
The only caveat I’d say is I prefer Roda over Rails for APIs and simple projects.
Do you happen to use rodauth with rails? And sequel?
My answer is probably seen as unconventional on Hacker News, but keep an open mind and you'll be pleasantly surprised.
I suggest you sign up for a free account at https://apex.oracle.com/ to try out Application Express (APEX). It's a free, web-based development tool for building modern, responsive and secure web applications.
It's a mature product that has existed for around 18 years, and it has a long list of features, check out the list here: https://apex.oracle.com/en/platform/features/
Since all these features are built in, you don't need to go shopping for the usual mix of libraries, build tools, external services, etc. For 95% of what you want to build, it's all there already as part of the framework.
The best thing is that you can get started and be developing web applications within minutes on this platform, without writing a single line of code. Even though you start out with no code/low code, you can add as much code as you want and go to any complexity later. The framework doesn't stop you from going "full code".
There's also a great, friendly and vibrant APEX community that shares experiences, develop plugins and tools, etc. See https://apex.oracle.com/en/community/community-resources/
Also, if you are worried about vendor lockin (any more than AWS or Azure or Google or whatever "framework du jour" locks you in), it should be noted that you can download and use APEX for free on your own infrastructure (or a DigitalOcean droplet or whatever). Also, APEX can run on the Express Edition (XE) of Oracle, so you can build and deploy web apps without ever having to pay Oracle a single dollar.
I suggest you sign up for a free account at https://apex.oracle.com/ to try out Application Express (APEX). It's a free, web-based development tool for building modern, responsive and secure web applications.
It's a mature product that has existed for around 18 years, and it has a long list of features, check out the list here: https://apex.oracle.com/en/platform/features/
Since all these features are built in, you don't need to go shopping for the usual mix of libraries, build tools, external services, etc. For 95% of what you want to build, it's all there already as part of the framework.
The best thing is that you can get started and be developing web applications within minutes on this platform, without writing a single line of code. Even though you start out with no code/low code, you can add as much code as you want and go to any complexity later. The framework doesn't stop you from going "full code".
There's also a great, friendly and vibrant APEX community that shares experiences, develop plugins and tools, etc. See https://apex.oracle.com/en/community/community-resources/
Also, if you are worried about vendor lockin (any more than AWS or Azure or Google or whatever "framework du jour" locks you in), it should be noted that you can download and use APEX for free on your own infrastructure (or a DigitalOcean droplet or whatever). Also, APEX can run on the Express Edition (XE) of Oracle, so you can build and deploy web apps without ever having to pay Oracle a single dollar.
Oracle and free in same sentence is laughable to say the least, everything they touch turns into money grabing venture, and even if free now there is no guarantee it will be free tomorrow.
The fact remains that Oracle has not charged a dollar for APEX for the last 18 years and counting.
If you have the luxury of picking your stack, and don't mind using modern, clean PHP, try Laravel and Forge.
Laravel is a solid framework, and Forge handles the deploys, even going so far as to be able to deploy automatically when you push to master. Plus, you can use Laravel Spark to build an application framework base, with user login, teams, payment, all that written for you.
If you're not able to pick your stack, well, Ansible is pretty easy to learn. You can use Vagrant for the local dev, and ansible-vault for production secrets management. Deploys become a single command line, and that includes when you want to push an environment update.
Laravel is a solid framework, and Forge handles the deploys, even going so far as to be able to deploy automatically when you push to master. Plus, you can use Laravel Spark to build an application framework base, with user login, teams, payment, all that written for you.
If you're not able to pick your stack, well, Ansible is pretty easy to learn. You can use Vagrant for the local dev, and ansible-vault for production secrets management. Deploys become a single command line, and that includes when you want to push an environment update.
I'll second this.
Laravel + Laravel Homestead (Pre-configured Vagrant VM) + Laravel Forge [2] (Server config + deployment processes) makes my life too easy.
It doesn't even have to be a PHP/Laravel project for this process to really make your life easy.
The Homestead VM has the same services installed and configured the same was as the forge server. Nginx (or Apache), mysql/mariadb, postgres, sqlite, node/bower/grunt/gulp, redis, memcached, beanstalkd, elasticsearch, go, etc
Homestead has pre-built commands to make it very easy to add new sites/projects, does the port forwarding for you, handles the shared folders easily. Forge's UI allows you to not have to ssh into the server for things like restarting nginx/mysql/postgres, 2 click let's encrypt SSL certs, configure/restart queue workers (via supervisord), configure cron scripts and schedules, deploy via git with custom deploy scripts. You can create databases, create database users and manager their permissions. Create firewall rules and manage daemons.
I spend all day in the PHP/Laravel ecosystem so it works for me - but I find myself pushing non-PHP products through the same pipeline most of the time because it's so easy and just works.
1. https://laravel.com/docs/5.6/homestead 2. https://forge.laravel.com/features
Laravel + Laravel Homestead (Pre-configured Vagrant VM) + Laravel Forge [2] (Server config + deployment processes) makes my life too easy.
It doesn't even have to be a PHP/Laravel project for this process to really make your life easy.
The Homestead VM has the same services installed and configured the same was as the forge server. Nginx (or Apache), mysql/mariadb, postgres, sqlite, node/bower/grunt/gulp, redis, memcached, beanstalkd, elasticsearch, go, etc
Homestead has pre-built commands to make it very easy to add new sites/projects, does the port forwarding for you, handles the shared folders easily. Forge's UI allows you to not have to ssh into the server for things like restarting nginx/mysql/postgres, 2 click let's encrypt SSL certs, configure/restart queue workers (via supervisord), configure cron scripts and schedules, deploy via git with custom deploy scripts. You can create databases, create database users and manager their permissions. Create firewall rules and manage daemons.
I spend all day in the PHP/Laravel ecosystem so it works for me - but I find myself pushing non-PHP products through the same pipeline most of the time because it's so easy and just works.
1. https://laravel.com/docs/5.6/homestead 2. https://forge.laravel.com/features
I use Django cookie-cutter(https://github.com/pydanny/cookiecutter-django) to quickly create a production-ready Django project with docker enabled. For Frontend, I use normal Django templates with intercoolerJS(http://intercoolerjs.org/docs.html).
It can be deployed on any docker machine with docker-compose.
It can be deployed on any docker machine with docker-compose.
Django, Docker and AWS ECS and ELB.
Absolutely worth the effort to learn how to build a Docker image and put together bash scripts to push the image and update an ECS service. We have a base project which includes nginx and uwsgi set up to simply serve the Django app and static files on port 80.
Having an ECS Docker cluster with spare capacity greatly assists getting new projects up and running quickly, especially if we can run the test site under an existing domain managed in AWS. Then we can just add new rules on an existing ELB and piggy back on the SSL certificate.
With this workflow we spend the time getting a good image running locally (with local environments vars/secrets) and we know the deployment side is taken care of, and can be scaled if and when is needed. This also has the benefit of forcing dependencies and environments to be fully documented from the start (in the Dockerfile).
The next step, if the project gains traction is to move the Docker build/push/service update into CI space. We've moved away from ansible now largely, there's a use case for more complex setups for sure but am interested in K8 capabilities to help there.
Absolutely worth the effort to learn how to build a Docker image and put together bash scripts to push the image and update an ECS service. We have a base project which includes nginx and uwsgi set up to simply serve the Django app and static files on port 80.
Having an ECS Docker cluster with spare capacity greatly assists getting new projects up and running quickly, especially if we can run the test site under an existing domain managed in AWS. Then we can just add new rules on an existing ELB and piggy back on the SSL certificate.
With this workflow we spend the time getting a good image running locally (with local environments vars/secrets) and we know the deployment side is taken care of, and can be scaled if and when is needed. This also has the benefit of forcing dependencies and environments to be fully documented from the start (in the Dockerfile).
The next step, if the project gains traction is to move the Docker build/push/service update into CI space. We've moved away from ansible now largely, there's a use case for more complex setups for sure but am interested in K8 capabilities to help there.
Agree with your tips, I’m personally hoping EKS becomes good enough that we can just skip the ECS step, but honestly translating basic ECS to Compose to Kubernetes (or any variation on that) is all all easy, so any of them work great to start
May I ask how you’re managing secrets with this setup? For example, the secret key or database URL.
Our current setup deploys an env file which is sourced before starting the process. I’m less sure how this translates to a production docket deployment.
Our current setup deploys an env file which is sourced before starting the process. I’m less sure how this translates to a production docket deployment.
Docker shouldn't affect your secrets management because secrets shouldn't be baked into your image anyways. I tend to expose them as environment vars and currently use Kubernetes to expose a keyvault url/password so the app can automatically grab all the secrets
We manage them with env vars now. But we use salt (encrypted) to deploy a secrets file onto the server which is sourced before the app is started. With something like ECS I didn’t know if you could feed it an env file, and if you could, how you could make it available.
In ECS you can store them in the task definitions which is easy but might not be secure enough in certain situations. More robust is to read them in from the Parameter Store see https://aws.amazon.com/blogs/compute/managing-secrets-for-am...
Thanks, exactly what I was looking for.
I've only been using Docker/ECS on side projects, but I generate the production build Docker image with the production .env included, push it to a private repo on Amazon ECR, then pull it in to ECS from there.
My understanding is the best practice for Docker/ECS production deployment is to create Docker images containing the full app build, rather than managing the app deployment separately from image deployment. As opposed to development Docker images that rely on docker-compose to mount the host filesystem in the Docker container, the production image Dockerfile includes COPY instructions for the production build files, to be included in the image.
My understanding is the best practice for Docker/ECS production deployment is to create Docker images containing the full app build, rather than managing the app deployment separately from image deployment. As opposed to development Docker images that rely on docker-compose to mount the host filesystem in the Docker container, the production image Dockerfile includes COPY instructions for the production build files, to be included in the image.
Python3 + tornado + peewee + sqlite3 + vuejs hosted on Digital Ocean.
I've been using this combo in production for https://www.cozycal.com for a year with no problems.
Likes: - More control than hosted environments - Dirt cheap
Dislikes: - More responsibility than hosted environments
I've been using this combo in production for https://www.cozycal.com for a year with no problems.
Likes: - More control than hosted environments - Dirt cheap
Dislikes: - More responsibility than hosted environments
It's still totally rails.
I mean... I can start a new project, create some models/tables and relations between them, and deploy it to heroku with admin login and decent interface and file upload... in half an hour?
and... this little project I create in half an hour, can be scaled up to handle tens of thousands of requests a second. Or wrapped with a native navigation and served up to mobile/desktop users, or integrate with any number of apis and services. And I can put it down for 5 years, come back and (almost)instantly know how to continue working on it; development in rails often has a certain obviousness to it. You spend time solving the interesting problems instead of the boring ones.
But the real kicker, is doing it in rails is enjoyable and effective; one person can deliver similar software that takes multiple teams many months to do in megacorps.
I've also had a number of managers hiring for phoenix/python/java stacks tell me they have a hard time finding the sort of developers they like working with outside of rails. I found that surprising - but rails does have a culture of effectiveness and happiness that other stacks do not share.
Anyway, If you have an idea and want to get something working but that can also carry you beyond prototype; Rails is a great choice. A complete development framework, well documented, great community, strong history, designed for enjoyment and effectiveness; that checks all the boxes for me.
I mean... I can start a new project, create some models/tables and relations between them, and deploy it to heroku with admin login and decent interface and file upload... in half an hour?
and... this little project I create in half an hour, can be scaled up to handle tens of thousands of requests a second. Or wrapped with a native navigation and served up to mobile/desktop users, or integrate with any number of apis and services. And I can put it down for 5 years, come back and (almost)instantly know how to continue working on it; development in rails often has a certain obviousness to it. You spend time solving the interesting problems instead of the boring ones.
But the real kicker, is doing it in rails is enjoyable and effective; one person can deliver similar software that takes multiple teams many months to do in megacorps.
I've also had a number of managers hiring for phoenix/python/java stacks tell me they have a hard time finding the sort of developers they like working with outside of rails. I found that surprising - but rails does have a culture of effectiveness and happiness that other stacks do not share.
Anyway, If you have an idea and want to get something working but that can also carry you beyond prototype; Rails is a great choice. A complete development framework, well documented, great community, strong history, designed for enjoyment and effectiveness; that checks all the boxes for me.
Serverless + managed cloud services for heavy lifting (cognito, dynamodb, cloudsearch) + basic logging, alerts, tracing stuff
static site or React on frontend
Pretty quick to roll out and free to run if the app never takes off. If you need to scale later, you can build your own serverless versions of some cloud services to save money.
static site or React on frontend
Pretty quick to roll out and free to run if the app never takes off. If you need to scale later, you can build your own serverless versions of some cloud services to save money.
wonder why this isn't getting more love?
Oh man no Java lovers here. I believe with the entry of Spring boot and Spring roo project which provide scaffolding and convention over configuration model, this just might be able to compete with RoR ecosystem in terms of speed and robustness.
Take a look: https://projects.spring.io/spring-roo/
Take a look: https://projects.spring.io/spring-roo/
1) Spring Boot on Google App Engine free tier
2) Managed Postgres on GCP/AWS
3) Frontend framework of the day, like React or Vue.
4) Take 1-2 hours in the beginning to set up ci/cd (like Circle) to make things 10x more convenient.
2) Managed Postgres on GCP/AWS
3) Frontend framework of the day, like React or Vue.
4) Take 1-2 hours in the beginning to set up ci/cd (like Circle) to make things 10x more convenient.
>4) Take 1-2 hours in the beginning to set up ci/cd (like Circle) to make things 10x more convenient.
Can you expand more on what you do here?
Can you expand more on what you do here?
Google App Engine free tier with Python Flask. I have my own starter repo:
https://github.com/klenwell/hip-flask
For a more full-featured boilerplate kit, see:
https://github.com/gae-init/gae-init
https://github.com/klenwell/hip-flask
For a more full-featured boilerplate kit, see:
https://github.com/gae-init/gae-init
The easiest thing to do is Heroku. They've really nailed it down and the +$2/month for their basic instance is easily worth it if you don't want to spend the time getting everything setup.
Automation requires infrastructure and infrastructure is cheap only if you know how to set it up.
I run ~3 side projects using Heroku to host a Django project with a GraphQL API talking to Heroku Postgres and Netlify the host the ReactJS frontend. I serve the API on heroku's free domain and put the react project under app.projectname.com and use token auth to talk to the API.
Deployments are super simple. Including updates to and managing the database.
Automation requires infrastructure and infrastructure is cheap only if you know how to set it up.
I run ~3 side projects using Heroku to host a Django project with a GraphQL API talking to Heroku Postgres and Netlify the host the ReactJS frontend. I serve the API on heroku's free domain and put the react project under app.projectname.com and use token auth to talk to the API.
Deployments are super simple. Including updates to and managing the database.
Sorry What did you mean by $+2? I see $7 for their hobby instance..?
I'm guessing he means "$2 more than a $5 droplet that you maintain yourself."
What do you use to connect Django models / Postgres to GraphQL?
Graphene does most of the work for me with Python meta-magic.
https://github.com/graphql-python/graphene-django
https://github.com/graphql-python/graphene-django
Usually CherryPy, Mako and MongoDB. Its how I won TADHack Mini 2018. I was able to focus on getting things to work more than how they work. CherryPy is older than Flask and OO based. Mako is a performant templating library that Reddit used and still might. MongoDB is just a document database so schema that changes isn't a big deal aka perfect for prototyping.
However I am making a shift to using D so I am learning DiamondMVC which is inspired by ASP .NET MVC and takes full advantage of Vibe.d and all the rest of the D ecosystem is available to me as a result. If I need something done in a weekend CherryPy and Mako with any DB.
If I wanna get something quick that I wont have to worry too much about scaling then D with Vibe.d or D with DiamondMVC is great. The best part about D is there is no crazy learning curve like Rust and it is very highly performant. Also the VS Code plugin is nice enough to make me productive enough.
However I am making a shift to using D so I am learning DiamondMVC which is inspired by ASP .NET MVC and takes full advantage of Vibe.d and all the rest of the D ecosystem is available to me as a result. If I need something done in a weekend CherryPy and Mako with any DB.
If I wanna get something quick that I wont have to worry too much about scaling then D with Vibe.d or D with DiamondMVC is great. The best part about D is there is no crazy learning curve like Rust and it is very highly performant. Also the VS Code plugin is nice enough to make me productive enough.
Reading this thread is making me want to write a blog post titled "Technology Fragmentation is Making Us Stupid and Wrecking Our Careers".
Every hour a developer spends learning a new language/stack/framework hotness is an hour that could be better spent studying something real, like mathematics, CS fundamentals, or UI design.
Every hour a developer spends learning a new language/stack/framework hotness is an hour that could be better spent studying something real, like mathematics, CS fundamentals, or UI design.
I used to chase the latest framework/language/hype machine and realized I was spending way too much time just playing catch up (this was especially the case with JavaScript/Coffeescript/Livescript/TypeScript...).
Now I’ve firmly put myself into focusing on one or two languages and learning them well, even as the “newest kid on the block” comes around that claims to want to replace every back-end language under the sun. It’s allowed me to focus on things like design patterns, integration development, and learning about infrastructure and good architecture principles, which I feel have added a lot more value than listing fifteen different “hot” skills on my resumé or whatever. I’m also a lot happier not having constant development information overload.
I get that keeping up with trends is a good thing to do, but sometimes you need to just ignore the chaos going on and plant yourself in one ecosystem for awhile just to take a breather.
Now I’ve firmly put myself into focusing on one or two languages and learning them well, even as the “newest kid on the block” comes around that claims to want to replace every back-end language under the sun. It’s allowed me to focus on things like design patterns, integration development, and learning about infrastructure and good architecture principles, which I feel have added a lot more value than listing fifteen different “hot” skills on my resumé or whatever. I’m also a lot happier not having constant development information overload.
I get that keeping up with trends is a good thing to do, but sometimes you need to just ignore the chaos going on and plant yourself in one ecosystem for awhile just to take a breather.
GatsbyJS with Netlify has auto deploy with git. I have not had an easier way to combine all the things I need for web as React is just bad ass, GatsbyJS has no webpack setup, Netlify combines hosting and deployment together and in a team if you need and it has cloud functions. I'm sorry if this sounds like a commercial for Netlify as I have no connection but I really like how it snaps together so easily.
Meteor JS with Meteor UP
https://www.meteor.com/ and http://meteor-up.com/
frontend: create-react-app
frontend hosting: surge.sh (free)
backend: node + socket.io (usually on a separate domain with CORS)
backend hosting: heroku (free)
database: MongoDB
database host: mlab (free)
everything in TypeScript, of course, because when you're in a hurry, you simply don't have time for your code to not be typesafe! (actually though, TS is a maaaaajor time saver, especially for smaller projects!)
frontend hosting: surge.sh (free)
backend: node + socket.io (usually on a separate domain with CORS)
backend hosting: heroku (free)
database: MongoDB
database host: mlab (free)
everything in TypeScript, of course, because when you're in a hurry, you simply don't have time for your code to not be typesafe! (actually though, TS is a maaaaajor time saver, especially for smaller projects!)
Imo Docker doesn't have too high a learning curve at the start. It's just when you move up to docker compose, Kubernetes that it can be overwhelming.
My opinion is that when you're starting out, just go with a PaaS like Heroku. You can simply maintain a separate dev/prod branch and it'll automatically update the server.
All the issues you mentioned can be solved it just takes some investment somewhere (time if you do it today yourself / money to pay a PaaS or someone else to do it).
We personally use Kubernetes to solve these issues since we get stateless builds and simply have environment variables that change things like database connections, api keys, etc between our various environments. But again this took a few weeks to setup.
My opinion is that when you're starting out, just go with a PaaS like Heroku. You can simply maintain a separate dev/prod branch and it'll automatically update the server.
All the issues you mentioned can be solved it just takes some investment somewhere (time if you do it today yourself / money to pay a PaaS or someone else to do it).
We personally use Kubernetes to solve these issues since we get stateless builds and simply have environment variables that change things like database connections, api keys, etc between our various environments. But again this took a few weeks to setup.
It may be too simplistic for most people’s needs but I’m a big fan of http://surge.sh/ for publishing simple, static sites.
we love netlify also
Rust + Diesel + Tokio.io + Postgres. I don't do web frontend (just apps and bots), and this stack took a LOT of time to get used to, but now I enjoy full static typing, perfect ORM-ish abstraction level (Diesel is kind of unique in that regard), built-in integration testing so it's compatible with SQL migrations and functions in Postgres and pretty good perfomance.
Could you elaborate on what you mean by built-in integration testing? I am using Rust now, full time, and can't wait for better testing support. There are RFCs to do just this. However, the current built-in testing situation leaves much for improvement.
Oh, I should've worded it better. It turns out it's pretty easy to set up Diesel to test your application code together with setting up a lock Postgres database. I had to put it up myself, but overall I just copied the approach Diesel uses for it's own integration test: have a test subproject and set up the database in it's custom compilation script.
https://github.com/diesel-rs/diesel/tree/master/diesel_tests
Now, every time I alter application code and/or SQL migrations, I immediately test them together automatically.
https://github.com/diesel-rs/diesel/tree/master/diesel_tests
Now, every time I alter application code and/or SQL migrations, I immediately test them together automatically.
I used Go and Elm most recently for building listenparadise.org a few weeks ago. Go is productive, simple and fast, and Elm also felt like that to me. You can read about why I quit JS in favor of Elm at http://azer.bike/journal/elm
I think Dokku solves a bunch of your pain points: https://github.com/dokku/dokku
Dokku is _preeeeeetty_ good but you kind of end up messing around on the server eventually to get things working, or fix things, etc.
If you're into that, or have CPU/RAM requirements that would be prohibitively expensive on Heroku then give it a try (I run it for a couple things on a cheap but powerful dedicated machine). If you're just doing something simple it's probably not worth it, just get a hobby dyno and go that route.
If you're into that, or have CPU/RAM requirements that would be prohibitively expensive on Heroku then give it a try (I run it for a couple things on a cheap but powerful dedicated machine). If you're just doing something simple it's probably not worth it, just get a hobby dyno and go that route.
MeteorJS (Node) + React for https://eddtor.com/editor, really quick (1 month from idea to launch), more recently going for Go full stack (server side + template/html package for front-end). After staying on the bleeding edge of Javascript ecosystem for about three years, I missed the simplicity of a reliable server-side language + the battle tested JQuery (I know, right?!) plug-ins.
- Vue.js
You can embed the Vue js file in your page, add <script></script> and you're ready to get started, no limits every feature is available. Of course for anything other than the most simple stuff you'll want some structure in your app so I use vue-cli which sets up the basic stuff.
- Cloud functions
Can be as simple as writing one in your browser in the azure/GCP/AWS console and as "complex" as using for example the serverless framework to deploy.
That's it!
You can embed the Vue js file in your page, add <script></script> and you're ready to get started, no limits every feature is available. Of course for anything other than the most simple stuff you'll want some structure in your app so I use vue-cli which sets up the basic stuff.
- Cloud functions
Can be as simple as writing one in your browser in the azure/GCP/AWS console and as "complex" as using for example the serverless framework to deploy.
That's it!
Rails + Postgres (+ Heroku if you need hosting)... same as 2008
Frontend:- React/Vue/Angular
Backend:- Spring Boot with Kotlin
I must say I am so impressed with what Pivotal did with Spring Boot. It’s amazing.
Backend:- Spring Boot with Kotlin
I must say I am so impressed with what Pivotal did with Spring Boot. It’s amazing.
It's so not fast to develop with though. I used to use it exclusively for years just cos that's what I knew. Switching to Rails now because Rails blows it out the water for speed of development. I still have a lot of love for Spring Boot just because of the power/flexibility and how incredible it is as a framework and marvel of engineering. But starting a spring boot app vs. starting a rails app is night and day in terms of how far along you already are with a Rails app especially if you use something like https://bullettrain.co
Vue + Rails 5.2 + Postgres + Dokku
With Bootstrap and Devise (auth) and many other ruby gems / npm packages, we can prototype a project extremely quickly with this stack by simply following the conventions of the community and trying to avoid writing too much custom code.
With Bootstrap and Devise (auth) and many other ruby gems / npm packages, we can prototype a project extremely quickly with this stack by simply following the conventions of the community and trying to avoid writing too much custom code.
Two part answer 1/ how do I built it 2/ how do I run it.
The run part became easy the last few years: Dockerize all the things, run them on AWS ECS with Fargate (and add whatever else you might need, e.g. ELB, S3, SQS, ...), no servers to setup or maintain.
The built part, that actually became harder... You need to figure out the best tools for whatever problem you're trying to solve, and the list of tools keeps growing. I default to very conservative standards, because I'm familiar and productive with them: Java (Spring Boot), Vue.js and PostGRES, with sometimes a bit of Node or Python and some ElasticSearch or DynamoDB thrown in the mix.
The run part became easy the last few years: Dockerize all the things, run them on AWS ECS with Fargate (and add whatever else you might need, e.g. ELB, S3, SQS, ...), no servers to setup or maintain.
The built part, that actually became harder... You need to figure out the best tools for whatever problem you're trying to solve, and the list of tools keeps growing. I default to very conservative standards, because I'm familiar and productive with them: Java (Spring Boot), Vue.js and PostGRES, with sometimes a bit of Node or Python and some ElasticSearch or DynamoDB thrown in the mix.
If you need an instant Backend (database + api builder) but also a CMS in the cloud you can check our combo:
Cloud Backend: https://cloudbackend.appdrag.com and Cloud CMS: https://appdrag.com
It's a fully serverless solution, nothing to install on your side, you can do everything in the browser directly. and we have a free tier :)
Also we have no lock-in, you can export everything in a ZIP, static files, db backup in mysql format, API source code in your language (Node.js, Python, Java, C#, Go, ...)
Cloud Backend: https://cloudbackend.appdrag.com and Cloud CMS: https://appdrag.com
It's a fully serverless solution, nothing to install on your side, you can do everything in the browser directly. and we have a free tier :)
Also we have no lock-in, you can export everything in a ZIP, static files, db backup in mysql format, API source code in your language (Node.js, Python, Java, C#, Go, ...)
Django running on Zappa (https://github.com/Miserlou/Zappa)
Thanks, this looks awesome. I didn't know django apps could run on lambda.
Looking for a self hosted solution that works like heroku, consider https://github.com/dokku/dokku
Been using that to host small projects here and there of late. Works well for keeping the app 12factor, and worry less about Devops
Been using that to host small projects here and there of late. Works well for keeping the app 12factor, and worry less about Devops
I like to use Vue included as a script tag with flask on the backend. Slightly outdated seed project: https://github.com/radusuciu/quickvue
I like it because it allows me to get started without thinking of any build steps.
I like it because it allows me to get started without thinking of any build steps.
I also use Django and Postgres. For deployment (keeping things in sync) I use Git :)
Set up your bare repository at say /root/myapp in your cloud server then clone this to your local dev area. Then clone it again to your cloud server django directories say /web/myapp . Finally git ignore you settings.py file so it can be different in each server.
This can actually scale up to reasonably sized prod/test/dev/local_dev cloud server setup by using appropriate branches though I know the traditionalists would be squirming in their seats.
Set up your bare repository at say /root/myapp in your cloud server then clone this to your local dev area. Then clone it again to your cloud server django directories say /web/myapp . Finally git ignore you settings.py file so it can be different in each server.
This can actually scale up to reasonably sized prod/test/dev/local_dev cloud server setup by using appropriate branches though I know the traditionalists would be squirming in their seats.
1) ASP MVC .NET Core 2 project
2) Get a linux vm
3) Write a WSL Script to push to linux vm (lftp + sshpass)
It tends to depend on what I'm setting up but these days I've shifted from Heroku onto services like now.sh and Netlify (not to discount Heroku as a viable option here) when I just need to get something online, quick and dirty. There's less commitment which is ideal because you're not going to know the full requirements for your app until you've begun to flesh it out more, so you can buy yourself some time to figure that out as you go along (e.g. what happens if you go for microservices?).
That said, never mind 2018...there are a whole load of joys (and horrors) that fresh devs these days won't ever really understand the same way because nothing like Docker or Heroku existed even just a decade ago.
You know, paying £3 a month for a shared hosting plan with 100MB disk space, and PHP4, phpmysql, Apache at your disposal.
Downloading FileZilla and deploying by dragging and dropping the new folder into the client, making sure to overwrite.
Debugging by using the same client to edit files and add logging in production.
Having to write htaccess rewrite rules for 'pretty' URLs that any developer today will think is just default behaviour for a web framework.
Having to use SVN and CVS, if using version control at all...
It's not like you can't still do any of this, it's just that dragging `index.php` into an FTP client isn't the default advice for deploying a simple site any more. For better and for worse.
That said, never mind 2018...there are a whole load of joys (and horrors) that fresh devs these days won't ever really understand the same way because nothing like Docker or Heroku existed even just a decade ago.
You know, paying £3 a month for a shared hosting plan with 100MB disk space, and PHP4, phpmysql, Apache at your disposal.
Downloading FileZilla and deploying by dragging and dropping the new folder into the client, making sure to overwrite.
Debugging by using the same client to edit files and add logging in production.
Having to write htaccess rewrite rules for 'pretty' URLs that any developer today will think is just default behaviour for a web framework.
Having to use SVN and CVS, if using version control at all...
It's not like you can't still do any of this, it's just that dragging `index.php` into an FTP client isn't the default advice for deploying a simple site any more. For better and for worse.
I just started at a new job where using filezilla to drag and drop changes is what has been done... It was previously one other dev working on it and after a week of there being me and him there were already a couple of major conflicts that happened. I set up git on the server so at least now we can do "git pull" like a real web company
I don't know how you guys did it 10 years ago, I couldn't even last 2 weeks with that system
I don't know how you guys did it 10 years ago, I couldn't even last 2 weeks with that system
On the framework side:
If you need an ORM and you don't need any interactive views then Django is a good choice. (Interactive views are views that are stateful in the browser: an interactive graph, an interactive table, a To-Do list, etc.)
If you need interactive views then you'll have much easier time using a React+Node.js framework such as Next.js (https://github.com/zeit/next.js) or Reframe (https://github.com/reframejs/reframe). And if you need an ORM you can use one of the many Node.js ORM such as https://github.com/typeorm/typeorm
If your site is static then go for a static site generator such as https://github.com/nozzle/react-static. ("Static sites" are webapps/websites that are HTML-static: The HTML doesn't need to be dynamically generated at request-time but is static, no server is required, and your app can be statically served.).
Disclaimer: I'm Reframe's author.
If you need an ORM and you don't need any interactive views then Django is a good choice. (Interactive views are views that are stateful in the browser: an interactive graph, an interactive table, a To-Do list, etc.)
If you need interactive views then you'll have much easier time using a React+Node.js framework such as Next.js (https://github.com/zeit/next.js) or Reframe (https://github.com/reframejs/reframe). And if you need an ORM you can use one of the many Node.js ORM such as https://github.com/typeorm/typeorm
If your site is static then go for a static site generator such as https://github.com/nozzle/react-static. ("Static sites" are webapps/websites that are HTML-static: The HTML doesn't need to be dynamically generated at request-time but is static, no server is required, and your app can be statically served.).
Disclaimer: I'm Reframe's author.
Three second setup of PHP sites with atomic updates and automatic DB migrations:
Pre-built LXD image with MariaDB, nginx and PHP. Git for deployment.
Provisioned and live in three seconds with support for rollbacks, migrations, atomic updates and zero downtime.
Should work well for most other scripting languages too.
Pre-built LXD image with MariaDB, nginx and PHP. Git for deployment.
Provisioned and live in three seconds with support for rollbacks, migrations, atomic updates and zero downtime.
Should work well for most other scripting languages too.
All you need is Laravel and Laravel Forge. Here is more detail on what I use https://timleland.com/side-project-tech-stack/
Elixir / Phoenix backend, React.js frontend. Nothing has beaten it in terms of development speed for me.
I created a project generator to solve that for my use cases: https://github.com/tiangolo/full-stack
It allows me (and the teams I work with) to go from clean Linux to web app 5 - 10 min while keeping best practices and allowing the system to scale.
It's all based on Docker and Docker in Swarm mode clusters (setup included in docs) Backend with Python Flask Interactive docs with Swagger/OpenAPI HTTPS automatic handling with Let's encrypt handled by Traefik Asynchronous tasks with Celery Front end with a modern SPA (Angular, React, Vue) Relational DB with Postgres, although I'm also using a modified version with CouchDB (I'll create a project generator with that later) CI/CD intergraded And more stuff...
It allows me (and the teams I work with) to go from clean Linux to web app 5 - 10 min while keeping best practices and allowing the system to scale.
It's all based on Docker and Docker in Swarm mode clusters (setup included in docs) Backend with Python Flask Interactive docs with Swagger/OpenAPI HTTPS automatic handling with Let's encrypt handled by Traefik Asynchronous tasks with Celery Front end with a modern SPA (Angular, React, Vue) Relational DB with Postgres, although I'm also using a modified version with CouchDB (I'll create a project generator with that later) CI/CD intergraded And more stuff...
Nodejs + Angular + Heroku. Surprised to see only 3-4 nodejs comments till now, compared to many more Go comments. Has the tide turned, is Go the new nodejs? :(
Go has some performance benefits over Node, especially when running CPU intensive tasks (Node is solid for I/O). They're both hugely successful platforms though. I think there are huge productivity advantages to using Node on the backend. Context switching between programming languages and platforms is expensive for humans, so...Node is a win for productivity if you already know JS well enough.
asking the same question i've asked all js-centric responses above... how do you handle authentication?
I use passportjs without thinking.
Clojure + pedestal on backend, ClojureScript + either om.next for complex projects or reagent for simple
The size of this discussion and the sheer number of different ways this can be done is mind boggling.
I'm all for having choices and I'm glad we're beyond choosing between FrontPage, Dreamweaver, and Notepad, but no wonder new people to web development are so overwhelmed.
I'm all for having choices and I'm glad we're beyond choosing between FrontPage, Dreamweaver, and Notepad, but no wonder new people to web development are so overwhelmed.
If I need a database I use Django on Heroku. It's free for up to 10,000 database rows and inexpensive should you need to grow past that.
If I don't need a database (or any persistent storage) I use Zeit Now, deploying Python apps (Django, Sanic or Uvicorn) via a Dockerfile.
If I don't need a database (or any persistent storage) I use Zeit Now, deploying Python apps (Django, Sanic or Uvicorn) via a Dockerfile.
Web2py (Python framework) includes an Ubuntu (and other) setup scripts plus a Fabric fab file for one command deploys that works pretty well. Web2py comes with a bootstrap welcome app that gives you user mgmt, authentication, admin and DB access with about a click.
I've web2py on digital ocean. A good thing is it's multi app so if you want another you click new and have a new hello world almost instantly. Setting up www.myhello-world.com and linking it takes about 5 min.
re
>A big aspect of what I'm wondering is about automatically setting something up for keeping local/production environments in sync, quickly deploying to production, and not having to mess with a bunch of server configuration things, user accounts, security, etc.
The config, accounts default to secure useable stuff
Auto is sync doesn't really happen but its a matter of clicking "pack all" on local web2py and then "upload" on the one on the server.
On the minus side it doesn't have that many users.
re
>A big aspect of what I'm wondering is about automatically setting something up for keeping local/production environments in sync, quickly deploying to production, and not having to mess with a bunch of server configuration things, user accounts, security, etc.
The config, accounts default to secure useable stuff
Auto is sync doesn't really happen but its a matter of clicking "pack all" on local web2py and then "upload" on the one on the server.
On the minus side it doesn't have that many users.
I have trouble understanding where all this demand for webapps come from. As a browser of the web, the only webapps I use are Google's email, maps, and docs. What are all these webapps for and why doesn't HTML (maybe with a touch of javascript) suffice?
I have a slightly different question - many of the answers in here make it sound like creating and deploying a new web app is practically a twice-a-week kind of thing for quite a few folks. What kinds of things are people so frequently creating and putting up in a hurry?
A large portion of the apps are intranet thing, instead of Internet. Business apps that are used in house.
Plus almost all websites are a kind of web app. And these have a complex backend for managing the content. While we browse the front end.
Plus almost all websites are a kind of web app. And these have a complex backend for managing the content. While we browse the front end.
I think you are underestimating what is a web app. Think about any website that requires a password - that is a web app because presumably it will do some personalization. Any content serving site is at least backed by a content management system which is a web app.
To me, "web application" is a front-end application that runs on the user's computer in a web browser. Having a back end that runs code doesn't qualify in my mind. Otherwise, basically any website qualifies as a web app, including one written in pure HTML, which doesn't make sense to me.
Zeit Now, without a doubt.
1. npm install -g now
2. run 'now' command in the folder containing your app files
The files are uploaded, your app is deployed and your clipboard contains the URL. So simple it's like cheating.
https://zeit.co/now
1. npm install -g now
2. run 'now' command in the folder containing your app files
The files are uploaded, your app is deployed and your clipboard contains the URL. So simple it's like cheating.
https://zeit.co/now
I was expecting to see more of Now in these comments. I don't have any real experience with it but it did seem like it would make deploying as simple as possible. Care to share any of your experiences with it?
Pure JS and GitHub Pages. Dead simple deploy, static pages, no dependencies other than browser compatibility. The web is fun and easy again.
Heroku is still a great choice if you're willing to pay to never think about infrastructure.
On the other hand if you're willing to ask for help there are plenty of freelance IT admins who would set up a digital ocean box with the DIY equivalent of Heroku.
On the other hand if you're willing to ask for help there are plenty of freelance IT admins who would set up a digital ocean box with the DIY equivalent of Heroku.
Strongly agree. I loved AWS Lambda both for pricing and for developer convenience/efficiency, but managing the network infrastructure beneath it finally irked me too much, so I switched to pushing a Docker container to Heroku and haven't looked back. I am tempted to believe that a lot of teams might be forcing themselves into over-engineering/overkill to jumping right to AWS where it's not needed.
I have read similar comments to the ones here about scaling and cost, so I might bump into that at some point.
I have read similar comments to the ones here about scaling and cost, so I might bump into that at some point.
I would not recommend this unless you hire these people for a regular maintenance role.
Leaving a box with no monitoring and no on-site skill capable of fixing it is a bad idea. That box will explode at some point and it's going to explode at the worst possible moment, and you'll loose tons of business (and/or data) while you scramble to get someone to repair it.
Unless you have people ready to jump in and fix it should it break, don't risk it and just let Heroku handle it.
Leaving a box with no monitoring and no on-site skill capable of fixing it is a bad idea. That box will explode at some point and it's going to explode at the worst possible moment, and you'll loose tons of business (and/or data) while you scramble to get someone to repair it.
Unless you have people ready to jump in and fix it should it break, don't risk it and just let Heroku handle it.
Not trying to be snarky but... how is it cheaper to hire a freelance IT person to set up something for you, and help you when it breaks/changes, than $7/mo for Heroku?
The issue with Heroku is it rapidly gets more than $7/month if you hit any sort of scale.
Absolutely. We went from free tier to about 100/month in nearly no time with Heroku. It’s worth it though. Heroku takes care of all sorts of stuff, and that fee is still cheaper than hiring a sys admin for a small business.
That is quite literally the price you pay for convenience. In many cases, that's a very rational tradeoff - your time is better spent on developing and marketing your app than dealing with devops. If your Heroku bill is a relevant business problem, then you're probably grossly under-charging for your app.
I think the main competition for Heroku these days is AWS and GCP. The workflow for deploying directly to managed cloud services has improved drastically over the last few years, so you might not need the niceties that Heroku offer.
I think the main competition for Heroku these days is AWS and GCP. The workflow for deploying directly to managed cloud services has improved drastically over the last few years, so you might not need the niceties that Heroku offer.
In my experience this is vastly overstated.
Also, just because you use Heroku for your app servers (dynos) doesn't mean you have to use it for everything.
Also, just because you use Heroku for your app servers (dynos) doesn't mean you have to use it for everything.
I’ve been happy with Dokku hosted on DigitalOcean with the Postgres plugin for persistance and the Grafana plugin for stats gathering (optimizing for validated learning). I have a base image of that on DO for new projects. (Also Dokku Postgres takes care of cron-based encrypted backups which it will happily store on DO Spaces; in case anything happens to your server) I use Node on the backend with a simple passport-based session cookie auth and the apollo GraphQL server for APIs. I use nuxt for isomorphic (progressive?) vue components along with the Apollo vue module to communicate with the GQL server.
If its a basic app with CRUD features, I use WordPress. Else PHP (LAMP stack) and JavaScript (MEAN stack) are great options.
The last couple prototypes I put up for work were using Flask and Vue on Heroku. I've been really happy with both how quickly they went up, but also how understandable everything is even a year later (they are only used internally).
The piece I wouldn't mind cutting out is heroku. If you do end up going the docker route, docker-machine is nice for being able to quickly put things up, "push" updates to digital ocean:
https://docs.docker.com/machine/examples/ocean/
The piece I wouldn't mind cutting out is heroku. If you do end up going the docker route, docker-machine is nice for being able to quickly put things up, "push" updates to digital ocean:
https://docs.docker.com/machine/examples/ocean/
Rails + whatever framework works for the desired frontend
Django or Flask, backed by PostgreSQL, both on Heroku.
Once you scale you can look into doing it manually with AWS when the cost savings start to become worthwhile (Heroku ends up being quite expensive for high traffic).
Once you scale you can look into doing it manually with AWS when the cost savings start to become worthwhile (Heroku ends up being quite expensive for high traffic).
This is what I use when I want to prototype something really quick.
VueJS
Surge.sh
Firebase (if there's a need to store data)
I think I already have a pretty established workflow when starting things up, due to numerous stuff I have built previously. Hence, the process of doing things multiple times (and making some tweaks to along the way) seems to make it really fast and straightforward.
My take is that just do repetitively what you feel comfortable at and at some point, you will reach a level where everything feels so easy and natural.
VueJS
Surge.sh
Firebase (if there's a need to store data)
I think I already have a pretty established workflow when starting things up, due to numerous stuff I have built previously. Hence, the process of doing things multiple times (and making some tweaks to along the way) seems to make it really fast and straightforward.
My take is that just do repetitively what you feel comfortable at and at some point, you will reach a level where everything feels so easy and natural.
Amazon Web Services free tier,
elastic beanstalk running node.js,
S3 for static files and stuff or basic web page hosting
or
Google Cloud free tier, Google App Engine running node.js, google cloud storage for static files and stuff or basic web page hosting
both are git-compatible and deployments are as easy as : "eb deploy" or "gcloud app deploy"
for front end stuff, if its just a prototype i just copy a bootstrap 'live preview' design that i like, and jquery stuff together.
or
Google Cloud free tier, Google App Engine running node.js, google cloud storage for static files and stuff or basic web page hosting
both are git-compatible and deployments are as easy as : "eb deploy" or "gcloud app deploy"
for front end stuff, if its just a prototype i just copy a bootstrap 'live preview' design that i like, and jquery stuff together.
I'm using Meteor with React and Semantic-UI-React. Not everything has to be realtime with Meteor; use Meteor.methods() instead. For most projects, I can definitely recommend using this stack.
https://www.meteor.com
https://react.semantic-ui.com
http://meteor-up.com
https://www.meteor.com
https://react.semantic-ui.com
http://meteor-up.com
> A big aspect of what I'm wondering is about automatically setting something up for keeping local/production environments in sync, quickly deploying to production, and not having to mess with a bunch of server configuration things, user accounts, security, etc.
Here's the simplest operational approach that I have yet found. Use Amazon RDS to run PostgreSQL as your production database. Architect your system to be one, static binary that is its own web server, contains all web assets compiled in, everything. It takes its configuration from a very small number of environment variables.
Start a CentOS VM. Copy the binary to it. Write a systemd service definition that sets the appropriate environment variables and runs the service as a dynamic user (so you don't have to worry about setting up accounts on the VM). Copy that definition to the VM and run `systemd daemon-reload` to make that service available. To deploy a new version, copy static binary of the new version to the VM and restart the service.
That glosses over lots of details, but it's your starting point for thinking about this. Every deviation adds operational complexity and has to pay for itself in reduced effort elsewhere.
Here's the simplest operational approach that I have yet found. Use Amazon RDS to run PostgreSQL as your production database. Architect your system to be one, static binary that is its own web server, contains all web assets compiled in, everything. It takes its configuration from a very small number of environment variables.
Start a CentOS VM. Copy the binary to it. Write a systemd service definition that sets the appropriate environment variables and runs the service as a dynamic user (so you don't have to worry about setting up accounts on the VM). Copy that definition to the VM and run `systemd daemon-reload` to make that service available. To deploy a new version, copy static binary of the new version to the VM and restart the service.
That glosses over lots of details, but it's your starting point for thinking about this. Every deviation adds operational complexity and has to pay for itself in reduced effort elsewhere.
Most languages don’t support static binaries. Other than Go I can’t think of any that make it easy.
Yup. It's a pain. A first compromise is to have the language runtime installed, and create a single file for your code and assets, such as a heavy JAR for JVM based languages or an egg in Python.
My preferred solution is Waxx https://www.waxx.io - It is Ruby and very fast. Mostly functions, no classes. Deploy like this:
waxx deploy stage or waxx deploy prod
The deploy script can be as simple as:
cd /path/to/folder && git pull && waxx migrate && waxx restart
Disclaimer: I am the author of Waxx and I wrote it to be as simple as possible yet still high performance and flexible.
waxx deploy stage or waxx deploy prod
The deploy script can be as simple as:
cd /path/to/folder && git pull && waxx migrate && waxx restart
Disclaimer: I am the author of Waxx and I wrote it to be as simple as possible yet still high performance and flexible.
First time I've heard of it - how would you say it compares with Rails? Is there much of a community behind it?
There is not much community yet. It is pretty new. It is very different than Rails. It is more of an RPC/Rest system than an MVC system. In my testing on FreeBSD with Postgres it is close to 10x faster than Rails. It is a bit faster than Go and a bit slower than Node. It is quite simple to write and the code itself can be read in a few hours (at most). I'll be posting some sample apps this summer.
After setting up server instances from scratch by hand multiple times over the years (and spending several hours each time), I finally bit the bullet and learned Ansible.
I can now take a bare VM image on DO/AWS to a fully functioning Django app.
I ended up modifying: https://github.com/jcalazan/ansible-django-stack
I can now take a bare VM image on DO/AWS to a fully functioning Django app.
I ended up modifying: https://github.com/jcalazan/ansible-django-stack
I use Django and jQuery on top of a pythonanywhere. A bunch of people say that you need PostgresSQL and MySQL setup. Or that you need gunicorn behind a nginx setup . I just don't do those things and run Django with Debugging off on pythonanywhere.com or on a VPS like Amazon Lightsail.
If you only need a static site though I have used Cactus but Jekyll could work.
If you only need a static site though I have used Cactus but Jekyll could work.
[deleted]
If I’m doing static html, even with minimal javascript perhaps even making an Ajax call client side, I am happy to use github pages or gitlab pages.
See here a 2 min video setting up a static html website with gitlab pages.
https://youtu.be/kvZ9teaA5zI
WeDeploy is less well known but offers a great (and growing) near-SaaS for building and deploying fully-featured web apps quickly. Surprising utility and my personal choice. I recommend checking it out and giving it a shot. Plus, the team there is responsive and always ready to listen to and meet user needs. Anyone else tried WeDeploy?
After reading most of the comments im really suprised to see folks still using vm servers and managing the stack themselves. Seems like high enough overhead.
I know cost is on peoples minds so why not serverless? Haven't seen anyone mention aws lambda or gcp cloud functions. You get a massive free tier , like 2 million requests and free db...
Anyone doing this?
I know cost is on peoples minds so why not serverless? Haven't seen anyone mention aws lambda or gcp cloud functions. You get a massive free tier , like 2 million requests and free db...
Anyone doing this?
yeah i feel like im so disconnected. there's literally one comment about aws lambdas, and a couple about firebase but pple still go "oh its so expensive" when in reality their stuff will almost never bust the free tier
React, Express, Postgress, Nginx all in Docker containers managed with Docker Machine on a Digital Ocean box. It may not be the most simple/quick solution, but with some copy/pasting I can get something up rather quick and it's super flexible. Need OCR? Add a Tesseract container. Need a fileserver? Etc.
how do you handle authentication?
Depends. Most of the time, I don't need any, because it's a quick 'n dirty proof of concept. For production, at work, we have a federated login, so external. For side projects, I use a good ol' Postgress table.
The “new” Microsoft stack is incredibly productive.
For $0 and less than 15 minutes I can spin up an ASP.NET Core app with Angular 6 with a free private git repo in VSTS. CI/CD fully setup to deploy to a free Azure App Service, for a few extra bucks per month I get deployment slots to separate out my dev/test/prod deployments. LetsEncrypt for SSL. Another $5 a month I get a fully managed SQL database that connects with my built in ASP.NET Core Identity to manage user logins, forgot passwords, etc. Auto-Healing, SSL, Backups, Geo-replication, AutoScale, DNS, CI/CD, cross platform IDEs, and feature/bug tracking are all included. So if my app gets hot I just pay more money to allow it to scale up and nothing else on my stack has to change.
All this in 15-30 minutes from my MacBook without fooling around with docker files, virtual machines, or Kubernetes.
For $0 and less than 15 minutes I can spin up an ASP.NET Core app with Angular 6 with a free private git repo in VSTS. CI/CD fully setup to deploy to a free Azure App Service, for a few extra bucks per month I get deployment slots to separate out my dev/test/prod deployments. LetsEncrypt for SSL. Another $5 a month I get a fully managed SQL database that connects with my built in ASP.NET Core Identity to manage user logins, forgot passwords, etc. Auto-Healing, SSL, Backups, Geo-replication, AutoScale, DNS, CI/CD, cross platform IDEs, and feature/bug tracking are all included. So if my app gets hot I just pay more money to allow it to scale up and nothing else on my stack has to change.
All this in 15-30 minutes from my MacBook without fooling around with docker files, virtual machines, or Kubernetes.
I wrote about it on my blog (that was in 2014 but nothing really changed since then).
http://readevalprint.tumblr.com/post/101841449553/its-alive-...
http://readevalprint.tumblr.com/post/101841449553/its-alive-...
I hope you are being sarcastic when you say, nothing really has changed since then.
I'm saying this regarding my architecture. If I started again, I'd probably use the same technologies. And, I mean, everyone else is recommending Django and Ruby on Rails which are even older so why would you pick on my comment specifically?
meteorJS(https://www.meteor.com/) seems to be one of the easiest framework you can use for building a web app quickly and pretty straightforward to deploy so you dont spend too much time is learning/setup etc...
For me, it's Laravel + Git(hub) + Bootstrap/AdminLTE/Whatever frontend.
But I already know this stack and I already have a server setup that can just let me fork a new app into one of the subdirectories or subdomains. If you want something public facing, there are only so many corners you can cut as being pwned is much more embarassing than having a prototype crash and burn during a demo.
Frameworks are good in that they let you make something fast + powerful without having to worry about alot of the details once it is setup. The problem is you have to tackle the learning curve for the setup. Finding something with good documentation is the best way to handle this even if it takes more work to learn than you want to spend on a "throwaway" project.
But I already know this stack and I already have a server setup that can just let me fork a new app into one of the subdirectories or subdomains. If you want something public facing, there are only so many corners you can cut as being pwned is much more embarassing than having a prototype crash and burn during a demo.
Frameworks are good in that they let you make something fast + powerful without having to worry about alot of the details once it is setup. The problem is you have to tackle the learning curve for the setup. Finding something with good documentation is the best way to handle this even if it takes more work to learn than you want to spend on a "throwaway" project.
Deriving an application using the best of frameworks - I believe is still very arduous. Yes, [ROR, Django,..] have helped but they kind of have been stagnant in their ease of deriving an app for many years.
Hence I am using a home-brewed stack on Express (Node.jS) + Nuxt (Vue.js) + MySql + Google App Engine.
This is based on Xmysql - which is absolutely a zero configuration way to derive REST APIs.
Xmysql : https://github.com/o1lab/xmysql/
I plan to make internal framework open source in coming few months.
It has built in features of regular frameworks + Authentication + Authorization + ACL + Payments (Stripe) + Microservice (google-cloud functions) + Pubsub (background jobs)..
Hence I am using a home-brewed stack on Express (Node.jS) + Nuxt (Vue.js) + MySql + Google App Engine.
This is based on Xmysql - which is absolutely a zero configuration way to derive REST APIs.
Xmysql : https://github.com/o1lab/xmysql/
I plan to make internal framework open source in coming few months.
It has built in features of regular frameworks + Authentication + Authorization + ACL + Payments (Stripe) + Microservice (google-cloud functions) + Pubsub (background jobs)..
Rails app started from a solid template deployed to Heroku takes minutes. This is what we use for all projects:
https://github.com/lockstep/rails_new
I've used https://github.com/apex/up and I like it a lot. With your AWS credentials configured in the environment, it boils down to running
$ upI find Linode/whatever with dokku and Django to be pretty quick and consistent. I have a dokku instance internally for testing, and do production deploys in the same way. It uses heroku buildpacks via herokuish which makes deploying anything straight forward.
Create Ubuntu VM (with applicable config (ssh keys only, automatic security updates, turn off cruft)
Install dokku
Install PostgreSQL plugin for dokku
Install letsencrypt plugin for dokku
Create app in dokku
Add remote in git repository locally
Add buildpack triggering things/stuff to let Django run in this environment (gunicorn, collectstatic stuff, etc)
Git push dokku
Why not using something already stacked like google App Engine? You can choose the language and not worry about the deployment. Or AWS Elastic Beanstalk? Same thing.
Everyone here seems to be posting their favorite stack when the question is about simplicity and quick iterations. I mean, my favorite stack would be a rails app running on docker and that would take me 1 hr to setup but only because I've done it dozens of times. If I didn't know how to configure an easy sync pipeline, I would go with the solutions I mentioned before. They both have wizards to guide the process the first time and you have a clear view of the costs.
The fastest way to get a web app running, for free is Rails + github + Heroku, imo.
It's very fast to scaffold a new app, with diverse options you'd want (react/vue/other stuff). Host it on github, create a heroku app and push it.
It's very fast to scaffold a new app, with diverse options you'd want (react/vue/other stuff). Host it on github, create a heroku app and push it.
What do you mean host it on github in the context of using Heroku, which would be your host? How is github involved?
Heroku has a github integration to handle CI and automatic deploys[1]. This way you can, for example, have your app deployed to heroku automatically when you update master, etc.
[1] https://devcenter.heroku.com/articles/github-integration
[1] https://devcenter.heroku.com/articles/github-integration
Well, he probably means source code management. However...if it's a SaaS you could have the marketing website hosted on github pages for free using Jekyll and that even incorporates a blog into your solution too! Then of course host the app on a subdomain using Heroku. So github can come into it that way if you think about it. Not a bad option at all!
I think the parent meant publish the repo on GitHub as you are unlikely to accidently nuke the code like you would if you were experimenting on Heroku.
I was mostly using with React and firebase for fast prototyping. Then I started using more of Flow to have some type safety. But overtime I started looking for a stronger type system that would allow me to experiment and build stuff easily. I feel like I started getting good enough with Purescript to build stuff fast, couldn't have the time yet to build a big thing to compare how fast my work flow is compared to react.
But I'm sure that I spend far less time debugging in Purescript than react, and bugs are mostly logical bugs that could be prevented with better types structure and testing with Quickcheck
I'd like to hear though from someone who's using F#, asp core with fable for example and know how the productivity is and the maturity of libraries.
The Crystal-language based Amber Framework (https://amberframework.org/) is a good framework to use if you want to ramp up a web application with a backend database and a full MVC stack in next to no time.
It also helps that it is an extremely fast framework. https://github.com/tbrand/which_is_the_fastest
Other frameworks like router.cr, Raze etc are faster performing, but getting started with a db middleware etc will take a bit longer.
It also helps that it is an extremely fast framework. https://github.com/tbrand/which_is_the_fastest
Other frameworks like router.cr, Raze etc are faster performing, but getting started with a db middleware etc will take a bit longer.
For my last project for a new business website, I just used Github pages w/ Cloudflare for SSL, all free.
Because the site needed a unique brand look n' feel, I opted out of Jekyll and used Foundation 6 as a base and node-sassed my styles with npm scripts and custom svg:s. For cache-busting I run hashmark with postbuild. Then I just write HTML.
Development is easy, things work nice, site is very fast and it looks great.
Moral of the story: starting with just static HTML and CSS is the right choice a lot of the time. Don't complicate things before you need to. And when the need to, only make dynamic those parts that can't be static.
Because the site needed a unique brand look n' feel, I opted out of Jekyll and used Foundation 6 as a base and node-sassed my styles with npm scripts and custom svg:s. For cache-busting I run hashmark with postbuild. Then I just write HTML.
Development is easy, things work nice, site is very fast and it looks great.
Moral of the story: starting with just static HTML and CSS is the right choice a lot of the time. Don't complicate things before you need to. And when the need to, only make dynamic those parts that can't be static.
+1 for Meteor
Also look into Bubble for really quickly getting something up and prototyping an idea.
Also look into Bubble for really quickly getting something up and prototyping an idea.
Firebase + NodeJS
::Firebase takes care of the authentication that's a big plus
and good videos in youtube(David east, Jen person, Chris esplion, Traverse media)
::Firebase provides you hosting as well with HTTPS.
Bubble.is - I can code all the languages needed to code my own site but Bubble made my latest project (sigparser.com) way quicker to develop than if I had tried to use one of the existing frameworks. If it was a really large project Bubble might not be what I use but for something smallish needing users and calling some APIs it was great.
I wrote this about my experience.
https://medium.com/@mendoza.paul/sigparser-creation-story-bu...
I wrote this about my experience.
https://medium.com/@mendoza.paul/sigparser-creation-story-bu...
I have a Django / Angular cookie cutter project that I use to start all my new websites.
The first thing I do is update them to the newest versions on the basic website, save that as my new cookie-cutter, then make the website.
The first thing I do is update them to the newest versions on the basic website, save that as my new cookie-cutter, then make the website.
I build many of my web app prototypes on WordPress. I give a talk about it: https://wordpress.tv/2017/06/05/corey-maass-rapid-web-app-de...
I had another idea last Thursday and had a prototype completed by the end of the weekend. WordPress takes care of ORM, routing, user management, admin and most of the features every web app requires. This leaves you to develop the actual unique selling proposition.
I had another idea last Thursday and had a prototype completed by the end of the weekend. WordPress takes care of ORM, routing, user management, admin and most of the features every web app requires. This leaves you to develop the actual unique selling proposition.
The simplest way that I find to get an webapp running is by using [parcel](https://github.com/parcel-bundler/parcel) for bundling the frontend and using a python [flask](http://flask.pocoo.org/) server for backend. I don't think it could get any simpler than this. Now if I have a database, I usually go with mongodb along with pymongo.
Go + HTML + CSS. Doesn't get much easier than `mkdir my-app` and you can sprinkle over fancier tech if and when you need it.
My specific Go toolset consists of the following packages:
* urfave/cli
* gorilla/mux
* html/template
* keyselhightower/envconfig
* database/sql
* rubenv/migrate
My specific Go toolset consists of the following packages:
* urfave/cli
* gorilla/mux
* html/template
* keyselhightower/envconfig
* database/sql
* rubenv/migrate
I wrote a NodeJS API "Kickstarter" to create my REST API quick and deploy them to Kubernetes (or Docker) easily: https://github.com/geekuillaume/nodejs-api-kickstarter. For the front-end, I use React-boilerlate: https://github.com/react-boilerplate/react-boilerplate
I've been getting into serverless computing for a few months now, and it's been a pretty good experience, and generally hassle free.
The only downside I saw was learning a bit of cloud formation to automatize the stack creation. But I guess if you want a quick prototype/deploy you might as well do it manually and learn it later.
I really recommend you to take a look at AWS's serverless products: https://aws.amazon.com/serverless/
The only downside I saw was learning a bit of cloud formation to automatize the stack creation. But I guess if you want a quick prototype/deploy you might as well do it manually and learn it later.
I really recommend you to take a look at AWS's serverless products: https://aws.amazon.com/serverless/
I don't do anything special for prototyping, I just use what I normally do if I were creating the real thing.
> django-admin startproject > copy+paste my webpack config for React > copy+paste my general management scripts into the package.json (mostly scripts to build the client, and if working locally also start a server)
Then if I want to deploy it, I just install nginx and gunicorn and again copy+paste my configs for those.
If I want to use mysql it's not too much trouble, takes 10 mins to get it up and running and my application hooked up to it.
> django-admin startproject > copy+paste my webpack config for React > copy+paste my general management scripts into the package.json (mostly scripts to build the client, and if working locally also start a server)
Then if I want to deploy it, I just install nginx and gunicorn and again copy+paste my configs for those.
If I want to use mysql it's not too much trouble, takes 10 mins to get it up and running and my application hooked up to it.
Yii2 with aws lightsail bitnami LAMP...mysql in the lightsail instance or RDS, nothing new or crazy but I know it and can get it done extremely quick.
If the webapp takes off, I can figure the rest out later.
If the webapp takes off, I can figure the rest out later.
Rails (server side rendering) + Heroku.
Check out https://aws.github.io/aws-amplify/
I haven't actually used it but looks pretty cool
I haven't actually used it but looks pretty cool
We use React + React Native + Nodejs + GraphQL to build web and mobile apps at https://ideatostartup.org
I love dokku for simple deployments. Even a blind truffle pig can do it on DO. Good for a bunch of microservices. Only issue at the moment is slapping Hugo on the raw domain.
How do you work with testing local changes outside dokku ? Because the one thing I've found with a docker setup is that I write increasing amounts of stub code to avoid going through the docker rebuild/redeploy cycle when doing development.
If your problem is about deployment, how about writing in Golang? You can build linux binaries even your machine is a Mac. Then you can just scp the binaries and run.
I'm experimenting with Anvil[0] at the moment. It's a bit like a web version of Delphi or Visual Basic. You build everything in Python. The front end stuff gets compiled to JavaScript. You can publish your app in a click. There is a built in database service, authentication and integrations with Google docs. It has a lot of potential.
[0]:https://anvil.works
[0]:https://anvil.works
Anvil is pretty sweet and had a well reviewed Show HN post a few months ago. Price is a little steep unless you plan to get serious, quickly.
I don't disagree, but do bear in mind
1) not everyone is a start-up. Established businesses also hand to put up web apps
2) you can use it for free with some limitations
3) Some other cloud services can work out quite expensive defending on your use case. Vs a Linode bare metal server, yes it is pricey, vs Heroku maybe less so?
1) not everyone is a start-up. Established businesses also hand to put up web apps
2) you can use it for free with some limitations
3) Some other cloud services can work out quite expensive defending on your use case. Vs a Linode bare metal server, yes it is pricey, vs Heroku maybe less so?
I like flask and I also like to use boilerplate or skeleton projects. These are projects that have a fair amount of infrastructure set up (testing, views, user accounts, even admin stuff). There are a lot of them set up on github with varying degrees of added features. I’ve begun to maintain my own for the sake of saving time.
The only challenge is setting up the appropriate infrastructure for deployment. Fabric works well for that.
The only challenge is setting up the appropriate infrastructure for deployment. Fabric works well for that.
Not sure if there is a much quicker way than using a solid monolithic such as Django or Ruby on Rails.
I'm used to React.js and TypeScript/GraphQL server on the backend. I would use Netlify to quickly deploy React.js and Apex Up to deploy the server to AWS Lambda. Apex Up doesn't really use AWS Lambda in the normal way. It will create a reverse proxy and each AWS Lambda function is like a mini server a la Heroku.
I'm used to React.js and TypeScript/GraphQL server on the backend. I would use Netlify to quickly deploy React.js and Apex Up to deploy the server to AWS Lambda. Apex Up doesn't really use AWS Lambda in the normal way. It will create a reverse proxy and each AWS Lambda function is like a mini server a la Heroku.
I use Rust and my own templates
Yesterday I setup my blog on Hugo. Very happy with that. Hugo is written in go but you only need to write markdown and deal with single config file. I managed to find theme that supprts overlay for images and various other options for images. Simplicity is the name of the theme. There are also themes with ready up forms, might be enough for your particular scenario.
I m pleasantly surprised to see Go so many times.
Flask hosted on pythonanywhere. Recommend highly.
1. flask-base for back-end
2. create-react-app for front-end
3. digital ocean for hosting
I just cp files from local to server and use a couple different bash scripts for dev vs prod.
2. create-react-app for front-end
3. digital ocean for hosting
I just cp files from local to server and use a couple different bash scripts for dev vs prod.
I try not to do this as I never bought into the idea of evolving a prototype into a production app.
My first prototypes tend to be in create-react-app with session-storage (state dies with browser session). I publish this as entirely static content on Amazon S3 (via CloudFront).
After that if the use case seems solid I choose the appropriate tech for the job
My first prototypes tend to be in create-react-app with session-storage (state dies with browser session). I publish this as entirely static content on Amazon S3 (via CloudFront).
After that if the use case seems solid I choose the appropriate tech for the job
Heroku, I don’t think it can be any easier.
create-react-app + netlify on the frontend. For the backend services, kubernetes on gcp with Ambassador from Datawire. It’s an extremely solid and easy to use gateway based on the Envoy load balancer. I have a few templates I’ve created that has reduced creating a new app/service down to a few keystrokes.
For every language, every framework, people are going to have their own favourite ways to actually make sites fast.
I'll say though, surge.sh is the fastest way to get up static sites and zeit is the fastest way to get up webservers. One command to deploy without any configuration and you're done.
I'll say though, surge.sh is the fastest way to get up static sites and zeit is the fastest way to get up webservers. One command to deploy without any configuration and you're done.
Quickly? Laravel Voyager. You can set up a functional app with several tables and relations between them and different access levels for different users - all this without one line of code (I'm not counting the artisan commands here). It's the shortcut of shortcuts.
I work at a Drupal shop so I'd probably just go with Drupal. Working with what you know is the fastest way to get stuff done. Drupal 8 is also quite a bit more elegant than the previous versions and the developer experience is pretty good nowadays.
I try not to do this as I never bought into the idea of evolving a prototype into a production app.
My first prototypes tend to be in create-react-app with session-storage (state dies with browser session).
After that if the use case seems solid I choose the appropriate tech for the job
My first prototypes tend to be in create-react-app with session-storage (state dies with browser session).
After that if the use case seems solid I choose the appropriate tech for the job
This might be of interest as well, since many web apps (but certainly not all) are CRUD apps: https://news.ycombinator.com/item?id=16508965
BOX: Digital ocean
API: flask + MySQL / Redis
UI: create-react-app
Use docker pre-build instances for MySQL or Redis or Nginx
If you have extra time in hand
Nginx --> flask
API: flask + MySQL / Redis
UI: create-react-app
Use docker pre-build instances for MySQL or Redis or Nginx
If you have extra time in hand
Nginx --> flask
Flask & SQLite running behind an Apache reverse proxy on an AWS Ubuntu server.
.net core + vanilla js + azure + mssql (which is non visible if you stick to the framework)
no need for FE framework unless you want a SPA.
you can get free credits on azure and deploy via VS code/studio in a click.
i am interested in something like this, if i can ask a few questions,
- is azure beginner friendly, for someone who has never done web app before?
- how does azure pricing and support turn out compared to other services mentioned around here?
- would it be easy as well to use PostgreSQL or some other database?
- is azure beginner friendly, for someone who has never done web app before?
- how does azure pricing and support turn out compared to other services mentioned around here?
- would it be easy as well to use PostgreSQL or some other database?
Kotlin, gradle, closure and tachyons.css.
I wrote a short buildscript for that setup that i copy.
I wrote a short buildscript for that setup that i copy.
Tachyons is really underrated. Not having to write CSS - and more importantly, not having to debug the CSS you write today in five years - is really great.
I've been using the Tachyons style since IE6 on my platform - never looked back!
https://meta-os.com/
It shrinks the total amount of CSS & style enormously as well.
I'm surprised noone mentioned ASP.NET yet.
With Visual Studio Code + .NET Core you have a completely free environment/framework that can run web applications on both Linux and Windows in minutes.
I'm a .NET fan but there's still some friction. There's Azure free tier to be sure, but I'm not sure about the backend - CosmosDB?.
I use my mini-Heroku PaaS (https://github.com/rcarmo/piku) and Redis/Postgres as a back-end
Hey Weston, with regard to servers and deployment, I think Heroku is a very turn-key solution. These days you can have a default `app.json` in your project and use it to click a button to deploy your app to a totally new development or production server including any databases and third-party add-ons you need provisioned for the app. It's pretty magical. For CI, I use Codeship. The combination of those two vastly minimizes my responsibility for infrastructure.
On the development side, I still think Rails is an excellent choice, but I also felt a lot of the same pain you're expressing, but instead of with server configuration, I started feeling it more specifically with the redundancy of putting together the same libraries over and over for each app.
To try to revive the joy of creating new projects, I created Bullet Train (https://bullettrain.co), which I describe as "Rails on Rails". It's an app template with authentication (Devise), authorization (CanCanCan), subscriptions (Koudoku), teams, invitations, OAuth integrations, etc. all wrapped in a consistent theme with a full feature-level test suite.
It also has a powerful code generation/scaffolding engine for pumping out CRUD views and controllers for the web, API endpoints, API documentation, and soon it'll handle your Zapier integration as well. (Posted a demo video of this here at https://twitter.com/andrewculver/status/934251715175395328) It also has a thin layer of conventions on top of vanilla Rails, like namespacing the public vs. account sections of an app. It's stuff that most of us were doing previously, just slightly different from app to app, and this is an attempt to standardize so we can build other magic on top of it.
As a demo, a few months ago I used Bullet Train + Heroku to build and launch a simple Trello clone in two hours: https://bt-cardboard.herokuapp.com/ . It's limited, and I haven't come back to it since, but I thought the end result was a powerful example of what you can get done quickly when you're using the right tools. (I have a video recording of the entire process which I'll upload to YouTube if anyone is interested in seeing it.)
Anyway, I wouldn't normally peddle my wares on HN, but the whole point of Bullet Train is to try to achieve new levels of developer productivity and happiness, which seemed relevant to the question you were asking. There's nothing quite like this in the Python world (I'm frequently told by Python developers,) but there probably should be, and I imagine it's just a matter of time before there is.
On the development side, I still think Rails is an excellent choice, but I also felt a lot of the same pain you're expressing, but instead of with server configuration, I started feeling it more specifically with the redundancy of putting together the same libraries over and over for each app.
To try to revive the joy of creating new projects, I created Bullet Train (https://bullettrain.co), which I describe as "Rails on Rails". It's an app template with authentication (Devise), authorization (CanCanCan), subscriptions (Koudoku), teams, invitations, OAuth integrations, etc. all wrapped in a consistent theme with a full feature-level test suite.
It also has a powerful code generation/scaffolding engine for pumping out CRUD views and controllers for the web, API endpoints, API documentation, and soon it'll handle your Zapier integration as well. (Posted a demo video of this here at https://twitter.com/andrewculver/status/934251715175395328) It also has a thin layer of conventions on top of vanilla Rails, like namespacing the public vs. account sections of an app. It's stuff that most of us were doing previously, just slightly different from app to app, and this is an attempt to standardize so we can build other magic on top of it.
As a demo, a few months ago I used Bullet Train + Heroku to build and launch a simple Trello clone in two hours: https://bt-cardboard.herokuapp.com/ . It's limited, and I haven't come back to it since, but I thought the end result was a powerful example of what you can get done quickly when you're using the right tools. (I have a video recording of the entire process which I'll upload to YouTube if anyone is interested in seeing it.)
Anyway, I wouldn't normally peddle my wares on HN, but the whole point of Bullet Train is to try to achieve new levels of developer productivity and happiness, which seemed relevant to the question you were asking. There's nothing quite like this in the Python world (I'm frequently told by Python developers,) but there probably should be, and I imagine it's just a matter of time before there is.
Gitlab-ci and Google app engine works for me as far as deployment goes. I won't discuss language/stack because the fastest there is "whatever you're used to."
For anything above basic level: Python/Django for backend, React front end.
Really basic (dynamic) stuff: Python/Django, straight up HTML/CSS
Static - Html/CSS with a sprinkle of vanilla Javascript.
Really basic (dynamic) stuff: Python/Django, straight up HTML/CSS
Static - Html/CSS with a sprinkle of vanilla Javascript.
VueJS with CouchDb. Especially for prototypes you end up rewriting everything multiple times. With classical orm-sql you lose way too much time with writing the boilerplate.
The most recent one I created was with Laravel hosted on Fortrabbit. If you want it to be even easier, try Laravel Spark. It is really easy to launch something simple.
Pythonanywhere and flask, with git used to deploy.
Fairly simple and I have not hit any performances or scale issues for any of the minor app apps I have made.
Ruby on Rails. You can't beat its development productivity given that you need web app. In the end, as others have said, it will be whatever you know best.
Heroku and node with any frontend framework of the moment
Docker containers are a breeze on heroku. The only issue is some wonkiness trying to ssh into the running container. Have yet to get it to work.
Google appengine. Just push the button, more or less.
If its just frontend web app, then Create React App (or React + Parcel)
If it is a complete web app, then Create React App (or React + Parcel) + AWS AppSync
If it is a complete web app, then Create React App (or React + Parcel) + AWS AppSync
For me, the fastest way to prototype is Glitch.com.
- It's instantly deployed
- Supports GIT
- Automatic npm installs when editing package.json
- You can access your virtual environment in an browser CLI
- It's instantly deployed
- Supports GIT
- Automatic npm installs when editing package.json
- You can access your virtual environment in an browser CLI
ember new my-app
Yes Ember is still great. Ember data has gotten bloated though so I say pull that shit out IMO unless you are really used to it.
Ember v3.0 is all modular now, so you can just strip out modules until you get down to Glimmer. Versus React or Vue where you start with basically nothing and build upwards.
Exact opposite philosophy, but way faster for building 90% of CRUD apps.
Yes Ember is still great. Ember data has gotten bloated though so I say pull that shit out IMO unless you are really used to it.
Ember v3.0 is all modular now, so you can just strip out modules until you get down to Glimmer. Versus React or Vue where you start with basically nothing and build upwards.
Exact opposite philosophy, but way faster for building 90% of CRUD apps.
emberjs + rails, I even built a starter template that can get a SAAS app up and running quickly and I built hyperlogs.com with it.
ember and rails are SUPER optimized for rapid development. You don't have to spend the next 3 weeks configuring a React app so it builds right :) . Not to mention the next time you do it, it will be different :).
ember and rails are SUPER optimized for rapid development. You don't have to spend the next 3 weeks configuring a React app so it builds right :) . Not to mention the next time you do it, it will be different :).
django-rest-framework + Bootstrap + plain JS frontend (not necessarily SPA-style, but can be)
I presume that some of the fancier new frontend options would be an easier way to consume a vanilla RESTy backend. Doing things this was also has the benefit that I can just hire somebody to write me a new frontend, since that's not really my forte.
I presume that some of the fancier new frontend options would be an easier way to consume a vanilla RESTy backend. Doing things this was also has the benefit that I can just hire somebody to write me a new frontend, since that's not really my forte.
Angular, host on S3 and serverless backend with AWS Lambda.
Build a client, write your routes and your good to go. Also scales really well.
Build a client, write your routes and your good to go. Also scales really well.
how do you handle authentication?
You can do signed cookies, validate in your lambda function the credentials, and then return a signed cookie. A little dirty, but quick and enough to lock-down
Rails still wins hands down when it comes to speed of development. I don't think anything else even comes close.
just learn docker and kubernetes, it just takes a couple of udemy courses.. it will make everything sooo much easier
Django on Heroku.
Use Heroku CLI 'heroku local web' to run locally and push to production via git.
Dancer in perl or Sinatra in Ruby. No DB, either a simple hash with proper locking or plain text files.
Firebase + VueJS or NodeJS + VueJS.
Firebase and Angular hosted in GCP.
Feathersjs + React or Angular
deployment with Docker which makes is easy to go Kubernetes if things scale up.
deployment with Docker which makes is easy to go Kubernetes if things scale up.
Digital Ocean, Laravel 5.6, Bootstrap 4, and git you can have a working site up in 2 hours.
fastest for me is just plain Sinatra and postgres. this is the gold standard of simplicity imo. and hosting for me is taken care of with Docker and an instance on Digitalocean. deployment is literally rsync and docker-compose up.
Apex Up, Express.js, and DynamoDB for the API, and then React for the front-end
At https://asyncy.com we are working to remove the unnecessary complexity of applications by choreographing microservices. We are just a couple weeks from private Beta. Would love your feedback and testing.
For me, I dig Spring Boot and Elastic Beanstalk. It's just:
mvn install; eb deploy
mvn install; eb deploy
Bulma.io, MLab, flask, nuxt and zappa.io and netlify for deployment.
Rails. Nothing comes close for me in terms of speed of development.
Flask(python) + SQLAlchemy(Any relational db) + Angular/React
Docker, Django, Caddy, Postgres, Digital Ocean.
Absolutely LOVE Django cookiecutter.
Absolutely LOVE Django cookiecutter.
As always jQuery HTML and CSS will quickly set up everything
Vue + Vuetify + go
Django + DigitalOcean + Vue.js(If necessary)
Outsystems PAAS www.outsystems.com
golang, amber (templates), gorilla mux, material-components-web, postgresql
deployed on aws or lightsail
deployed on aws or lightsail
flask + vue
flask + heroku + flask-sqlalchemy to talk to the easy postgres heroku gives you
zeit.co 's "now". So simple, no cost to get started.
Next.js + Prisma graphql
Express + React + Redux
AppEngine + Go + Gin.
Play for Scala
create-react-app and netlify.
WeDeploy.
As someone who operates a consultancy which has deployed more than 5000+ web apps in the last quarter alone.
We exclusively use AWS Lambda, DynamoDB or if the app is complex, we use Amazon RDS.
For search - AWS Elasticsearch
Our preferred stack is Go + VueJS.
WHY GO?
It's much easier for our senior developers to ramp up a team of 10 developers on Go than say Python or Ruby. Suprinsgly, we have a few guys who are Go experts, they unblock all other developers when it comes to best practices or some weird bugs.
WHY VUEJS?
It's has been a lot easier for us to introduce this to our frontend developers than any other thing.
WHY NOT RAILS?
We found it difficult to make SPA apps in Rails and ramp period for developers is much higher than Go + Vuejs.
WHY NOT PYTHON?
I loved Flask but we really need Type checking, we are not able to sleep without it. And Go has enough of what we need. Yes, we've briefly experimented with Haskell, OCaml, Scala etc.... but way difficult for new devs.
WHY NOT JAVASCRIPT BACKEND?
We found it much easier to write backend code in Go.
IDE/DEBUGGER
I am a pro-VIM user myself but it's so refreshing and fun to watch new developers speed up on Gogland IDE and the debugger makes developing in Go much easier. This is something only old languages like Java or C# has. It's way more difficult for new developers to pick up Java or C# in our experience. They've way more features which our developers found confusing. So, Go stayed everything else was thrown out including Haskell.
VUE CLI
We use https://github.com/vuejs/vue-cli No it does not require deep knowledge of webpack. There are just a few guys on our team who knows webpack/vuejs/javascript inside out in extensive details, rest of the developers simply use their custom designed/documented template and it satisfies 100% of our frontend needs. They unblock everyone on our team if any developer gets stuck with webpack.
DEVELOPERS ARE OUR BIGGEST COST
Keep in mind, we do not have access to the best developers at the budget price.
TRAINING
We give new developers as much help and training as they need. Our developers can call the pro guys anytime (even on weekends) and our senior developers love the respect/rewards they get in return.
COST
AppEngine costs $30 a pop, for 90% apps which receive less than 100 hits a day, it's expensive. This is where Lambda wins.
CI
Multi-tenant CI is still a pain in 2018. Current workflow with Gitlab sucks. We wish we could have a simple file in our repo and make 1 curl call to run the CI without any initial setup. But it will eventually happen.
PAYMENT PROCESSING
If the SaaS product needs multiple payment methods like Stripe, Braintree, PayPal Bitcoins, Ethereum, Wire Transfer we use http://killbill.io/ which is multi-tenant, opensource and self-hosted. Previously, we were using WHMCS, Amember pro, and Chargify but it ended up costing way more and was a lot more fragile at the end, completely failing monkey wrench test and our new developers found it much harder to wrap their head around 3 different products. A customer has to simply enter their API credentials for the respective gateway (Stripe or PayBear or BitPay) and we integrate it in minutes.
BIGDATA
If we need complex large aggregation, we haul in Athena or BigQuery.
Our developers prefer BigQuery but Athena is sometimes cheaper in the long run and makes it way easier to import/partition your big data.
STREAM PROCESSING
If we need anomaly detection or preprocessing of statistics we use Kinesis streams.
Because of this setup, we primary run on an army of bootcamp graduates and we are able to provide really cheap service to non-profits and other companies who are not able to afford even a dedicated freelancer.
FORGET VALUE, WE WANT TO BE CHEAP
"Cheap" is a wrong word to use as a marketer/sales guy. But yea, since I am now in technical position, so I remove sales guy hate and wear tech hat, making our creation as cheap, robust and secure as possible while still satisfying the requirements.
WHERE IS THE FUN
We drive our major profits from AdTech business (which involves stressful high tech stuff but it's lot more fun) and consultancy is just to validate our solutions across a large number of our portfolio customers. We've to ensure, their setup is as cheap, robust and secure as possible.
IMPROVEMENTS
As I want to improve my strategies and methods as much as possible, feel free to challenge my choice. It should not just work for 1 developer but an army of developers and it should make it trivial to add more developers.
We exclusively use AWS Lambda, DynamoDB or if the app is complex, we use Amazon RDS.
For search - AWS Elasticsearch
Our preferred stack is Go + VueJS.
WHY GO?
It's much easier for our senior developers to ramp up a team of 10 developers on Go than say Python or Ruby. Suprinsgly, we have a few guys who are Go experts, they unblock all other developers when it comes to best practices or some weird bugs.
WHY VUEJS?
It's has been a lot easier for us to introduce this to our frontend developers than any other thing.
WHY NOT RAILS?
We found it difficult to make SPA apps in Rails and ramp period for developers is much higher than Go + Vuejs.
WHY NOT PYTHON?
I loved Flask but we really need Type checking, we are not able to sleep without it. And Go has enough of what we need. Yes, we've briefly experimented with Haskell, OCaml, Scala etc.... but way difficult for new devs.
WHY NOT JAVASCRIPT BACKEND?
We found it much easier to write backend code in Go.
IDE/DEBUGGER
I am a pro-VIM user myself but it's so refreshing and fun to watch new developers speed up on Gogland IDE and the debugger makes developing in Go much easier. This is something only old languages like Java or C# has. It's way more difficult for new developers to pick up Java or C# in our experience. They've way more features which our developers found confusing. So, Go stayed everything else was thrown out including Haskell.
VUE CLI
We use https://github.com/vuejs/vue-cli No it does not require deep knowledge of webpack. There are just a few guys on our team who knows webpack/vuejs/javascript inside out in extensive details, rest of the developers simply use their custom designed/documented template and it satisfies 100% of our frontend needs. They unblock everyone on our team if any developer gets stuck with webpack.
DEVELOPERS ARE OUR BIGGEST COST
Keep in mind, we do not have access to the best developers at the budget price.
TRAINING
We give new developers as much help and training as they need. Our developers can call the pro guys anytime (even on weekends) and our senior developers love the respect/rewards they get in return.
COST
AppEngine costs $30 a pop, for 90% apps which receive less than 100 hits a day, it's expensive. This is where Lambda wins.
CI
Multi-tenant CI is still a pain in 2018. Current workflow with Gitlab sucks. We wish we could have a simple file in our repo and make 1 curl call to run the CI without any initial setup. But it will eventually happen.
PAYMENT PROCESSING
If the SaaS product needs multiple payment methods like Stripe, Braintree, PayPal Bitcoins, Ethereum, Wire Transfer we use http://killbill.io/ which is multi-tenant, opensource and self-hosted. Previously, we were using WHMCS, Amember pro, and Chargify but it ended up costing way more and was a lot more fragile at the end, completely failing monkey wrench test and our new developers found it much harder to wrap their head around 3 different products. A customer has to simply enter their API credentials for the respective gateway (Stripe or PayBear or BitPay) and we integrate it in minutes.
BIGDATA
If we need complex large aggregation, we haul in Athena or BigQuery.
Our developers prefer BigQuery but Athena is sometimes cheaper in the long run and makes it way easier to import/partition your big data.
STREAM PROCESSING
If we need anomaly detection or preprocessing of statistics we use Kinesis streams.
Because of this setup, we primary run on an army of bootcamp graduates and we are able to provide really cheap service to non-profits and other companies who are not able to afford even a dedicated freelancer.
FORGET VALUE, WE WANT TO BE CHEAP
"Cheap" is a wrong word to use as a marketer/sales guy. But yea, since I am now in technical position, so I remove sales guy hate and wear tech hat, making our creation as cheap, robust and secure as possible while still satisfying the requirements.
WHERE IS THE FUN
We drive our major profits from AdTech business (which involves stressful high tech stuff but it's lot more fun) and consultancy is just to validate our solutions across a large number of our portfolio customers. We've to ensure, their setup is as cheap, robust and secure as possible.
IMPROVEMENTS
As I want to improve my strategies and methods as much as possible, feel free to challenge my choice. It should not just work for 1 developer but an army of developers and it should make it trivial to add more developers.
Interesting to hear you're using Go and Vue.js.
With Go, are you using off-the-shelf web frameworks or libraries or do you have your own in-house framework/template?
So you said you're deploying 5000+ web apps a quarter. Are those new web apps? How many web apps are you deploying per dev head count?
With Go, are you using off-the-shelf web frameworks or libraries or do you have your own in-house framework/template?
So you said you're deploying 5000+ web apps a quarter. Are those new web apps? How many web apps are you deploying per dev head count?
With Go, are you using off-the-shelf web frameworks or libraries or do you have your own in-house framework/template?
No frameworks. We use http://www.gorillatoolkit.org/pkg/mux and sometimes we need a few more libraries for GWT/ElasticSearch/PostGres. I know there more performant options but we've found no reason to change so far.
So you said you're deploying 5000+ web apps a quarter. Are those new web apps?
Yes, 70-80% of them are new apps. Small apps, not multiple month project, mostly CRUD. Much easier/faster and cost-effective for us to develop what we've already done. OId app usually requires adding few routes and shuffling around the frontend elements or adding some small CSS tweaks. We use a simple list to accept/reject projects. We never undertake any complex project.
How many web apps are you deploying per dev head count?
These are small apps. We've 1500 developers in a very low-cost jurisdiction.
No frameworks. We use http://www.gorillatoolkit.org/pkg/mux and sometimes we need a few more libraries for GWT/ElasticSearch/PostGres. I know there more performant options but we've found no reason to change so far.
So you said you're deploying 5000+ web apps a quarter. Are those new web apps?
Yes, 70-80% of them are new apps. Small apps, not multiple month project, mostly CRUD. Much easier/faster and cost-effective for us to develop what we've already done. OId app usually requires adding few routes and shuffling around the frontend elements or adding some small CSS tweaks. We use a simple list to accept/reject projects. We never undertake any complex project.
How many web apps are you deploying per dev head count?
These are small apps. We've 1500 developers in a very low-cost jurisdiction.
Heroku + AWS' RDS for Postgres
I just make a spring boot seed application and use it whenever I start new projects.
create-react-app
Same. As for deployment depends somewhat on the back-end but I tend to use elastic bean stalk if I’m aws.
OUTSYSTEMS.COM
No need to thank me.
I once wrote to them to ask the cost.
>12 Months Committed Agreement at £15,000 for 150,000 Software Units and 100 active users
Seemed steep for 100 users.
>12 Months Committed Agreement at £15,000 for 150,000 Software Units and 100 active users
Seemed steep for 100 users.
What services and technologies do you use when you'd like to quickly build a web app which may never be more than a prototype, but may also turn into something real? A big aspect of what I'm wondering is about automatically setting something up for keeping local/production environments in sync, quickly deploying to production, and not having to mess with a bunch of server configuration things, user accounts, security, etc.