For when you need to keep sensitive data or apps inside your firewall. Anvil on-site installations allow you to develop and deploy your apps entirely in-house.
I was thinking more in terms of ameliorating the risk of building a successful small business on this and them going out of business after gorging themselves on VC money and having a heart attack.
You could probably rewrite your thing in Django or similar in the event of that. Given that the majority of web apps don't turn into successful small business it might be a good way to try stuff.
My use case is closer to being a small dev shop doing webapps for other people. If they go out of business, I would have tons of Django/whatever work all of a sudden, but lots of pissed off customers when I don't have time to rewrite them all. Plus I (morally) would need to warn them about this risk when pitching/selling them, which would probably put a sizeable dent in sales: "Also, there's a chance that this completely separate company stops supporting their product and we have to charge you for a complete rewrite of your app".
Glad to hear it! Some details about the tech stack:
* Front-end code is compiled from Python to JS with Skulpt (http://skulpt.org)
* The back-end code runs in a custom Python sandbox. Calls to server functions go over a secure web socket (this lets us do fun things like returning database rows directly from server functions, rather than faffing with REST APIs all day)
* The built-in database (Data Tables) is based on Postgres, using its JSONB and GIN indexing to create a table you can search efficiently on any column. This also means that things like transactions are properly robust.
Interesting. I've been looking for alternatives to React or Angular for some time. I've enjoyed playing with Elm recently. My preferred back end is Python Tornado RethinkDB, so browser GUIs in Python is appealing. I looked at https://github.com/skulpt and it looks like the compile to JS step happens on the client side, unlike Elm. What's performance like?
From the Skulpt website: "Skulpt is an entirely in-browser implementation of Python."
It sounds like you implemented python in JS, so there is no compilation to JS. The application code is always python and is evaluated on the client, no?
If you move it to the back end, would that not be something like Trascrypt?
Skulpt has a separate compiler stage that compiles Python to JS, and a runtime library. There's no need to eval() that code in the same JS VM that compiled it, so it's totally feasible to ship the JS to the client and run it there.
As far as I can tell, the footprint is around 1MB for the combined skulpt-min.js and sculpt-stdlib.js (not sure why the latter apparently isn't minified). That's pretty huge and makes for a large barrier against using Anvil for a public-facing app. Moving the compilation to the back-end would eliminate the footprint problem -- or would you still have the stdlib running in the client? Any further comments on footprint issues? As it is, we're talking about about two orders of magnitude bigger footprint than some javascript options.
Honestly, we would absolutely love to open-source it! The issue is that we're a bootstrapped start-up, and it's rather difficult to make open source pay the bills, even if it becomes huge (see, eg, Docker's troubles). By charging for the product, we can claim some of the value we create, and be sustainable so the platform stays around.
Are you worried about would-be customers self hosting? Because I doubt there’s that much overlap between would-be monthly customers and those who are eager to self host.
For a counter-example, see RedHat :) I can certainly understand your position, but it isn't impossible to make money from Open Source. One approach to get some funding might be a KickStarter or Patreon type offering. (Or a combination of both). You also have your hosting service. Just some ideas, there are lots of open source business models- good luck whatever you decide.
RedHat was bought and incorporated by a pre-existing business. It wasn't bootstrapped.
I'd also discourage a patreon- or kickstarter-style offering for a B2B product, because it signals very clearly that you're not playing with the big fish.
Not a bootstrapped business, you mean, like Docker (Explicitly used as an example, to which I was providing a counter-example)?
As for signaling, one would not have to use those providers if they felt it did not fit their brand, and could roll their own platform. But if signaling that you want to "play with the big fish" is what one wants, most companies hire sales team who go out and play golf with prospects. Having an open source product and using other forms of funding certainly does not preclude doing that. (Though being a small bootstrapped business might make it more difficult).
Perhaps a clear migration path from Anvil-infused Python to vanilla Python / JavaScript would be a reasonable approach. If for one reason or another I have to move my apps elsewhere I'd would like an easy way to do so rather than being permanently locked into a specific vendor.
At my entreprise, they are paying per seat to use gnat compiler. Even if it is open source and free to use for non commercial use, you can sell it and expect that your potential clients will generally not cheat.
I can't see my company (a small business with a number of small apps, with engineering and marketing people who it'd be great if they could just use something like this to build some things themselves) ever using something like this that is both closed source and somewhat prone to lock in by the nature of how it works.
While charging for use might seem like a good business model, I think an awful lot of potential customers will just never use it because of it. You may be able to find a model where you charge for the front-end page designer or something, but open source everything needed to run the site so that being locked in to a product you have to pay for and can't modify is less of a concern.
This is a really hard question to answer. We've got everyone from scrappy one-person startups building products on Anvil, to larger startups pumping terrifying quantities of money through Anvil apps, to Seriously Large Companies We Can't Name building internal tools with our on-premises version.
Right now we're taking it all as it comes, but we never want to lose our focus on accessibility: It's way too hard to build web apps with today's traditional tools, and we want to make it easier for everyone.
We use the Skulpt Python-to-Javascript compiler (I'm a maintainer): http://skulpt.org
You might be interested in my talk from PyCon US this summer, where I talked about the compiler, and how we turn blocking Python code into non-blocking Javascript code:
I'm really not a fan of Python client side. Or RAD. Or closed source services.
And I'm hugely impressed by the potential of your product.
Good luck.
I never though I would say that one day. But don't listen to people asking you to open sourcing it now. You can always do it once you are profitable. But right now, you need money to get this going. And if your product does what you say it does, people will be happy to pay.
Although not to be locked up on the long run. You will need to address that one day. One day.
Awesome stuff. Are there any debugging capabilities? Being able to inspect variables and step through code is massively valuable, particularly for education, but also for devs.
Wow this is pretty impressive! Python everywhere is a big advantage and the way the frontend, backend and database are integrated appears quite seamless.
My question is about scaling - what are some large apps on this platform and how big do you think these apps can get in terms of db size and qps?
Our infrastructure is all on AWS and designed to scale horizontally, so we're pretty confident we can handle whatever traffic you throw at your app. (Ask about our dedicated-resource hosting plans!)
As for examples, it's a bit Catch-22. Our smaller customers, you haven't heard of; and our largest ones, we can't talk about in public. And a lot of it is internal/intranet stuff anyway.
I just had a video demo tutorial with your colleague @daviesian. He is such an intelligent and effective communicator. I learned a lot about your platform in a short 30-minute screen sharing.
In the crowded world of PaaS, human factors might have equal (if not more) importance than the technology magic. From my experience with Ian, I do see the bright future of your platform. You have a great team that people will trust.
I remember someone saying on HN that what the world needed was a way to make web apps that was as easy as making a Windows form in Visual Studio. Could this be that app?
Whenever i see these cloud apps that seem like a good idea, I just think of spiralling costs similar to the likes of firebase written about on HN before.
Their pricing page doesn't show anything about usage limits and if it is "per site" or "per domain" or "per project".
Pricing is per-developer-seat; we don't limit the number of apps you can build or publish.
Usage limits are pretty soft right now (depends heavily on what you do in your code and how hard you're hammering our servers), but the general intention is to charge you more as you scale up your team, rather than because you got a few thousand users.
Does Anvil render server-side or is it client-side only?
My issue is if being used for websites, on average our sites get ~50k visitors a month or even spikes with that amount.
The same goes for complexity of the system, for simple html sites it will not matter much but for very dynamic apps this will require a lot of CPU time.
Reading the docs, it says the Forms run on the client, so most rendering should run too. Client-side rendering - while it has its disadvantages - shouldn't be worse for the CPU time than server-side, though. What's your concern?
So as long as I build the next Twitch on my own you guys will just charge me $50 per month? That’s freaking awesome! It’ll save me $5300 per month in hosting already!
It is this lack of clarity (published limits) that scares many of us. It basically says that we won't know when we'll be cut off or shut down, but we'll find out when it happens!
So if we build something that becomes wildly successful, we could suddenly be in a world of hurt if our site is deemed too heavy and we're throttled or worse. It would be like Pokemon Go - big explosion, lots of tiny pieces, customers gone.
I urge you to have some kind of professional plan with guaranteed tiers. Otherwise, only naive people or people who really don't care about the future will use it (outside of the prototyping case everyone else is mentioning).
On the other hand, it would be the perfect tool for someone on upwork or the like to do a gig ultra fast, leaving the client to deal with all the future pains. But since most projects end up not huge and successful, that might be just fine!
I only watched the video, so it is a bit early to judge, but I wonder:
1. Why put that much effort in explaining it takes only 6 minutes in setting up a web app? Anyone who has done any serious web app knows how quickly you can set up a simple app really does not matter much for an app even of moderate size, let alone big ones?
2. Why yet another attempt to abstract away everything and using one language (python) only? What happens when you need to debug nitti-gritty js/css/html/sql?
These tools are for simple CRUD apps for people who aren't necessarily strong developers to begin with but need to put together something anyway. That's why the demos focus on speed and only ever show the tiniest of applications.
I'd dispute that! There are much larger applications built on Anvil; it's just hard to build a two-week project for a demo video, and harder still to build a two-month one ;)
We're starting to post some larger examples (check out our "download portal" example at https://anvil.works/learn#examples - I'm also working on a video series building a SaaS app over the course of a few hours). But the biggest apps are, of course, our customers', and we can't really publish them as examples.
Fair enough. I may have been a bit harsh (though not really on purpose). I'll look through some of the larger examples. I just tend to think that if one's team has the chops to write something large and more complicated than a CRUD app, they aren't going to want to start here. That's not to say there's not a role for these types of tools...
Their control panel drives companies' entire online marketing operation - creative, targeting, performance, and more - across multiple advertising services. That's a whole lotta UI. Their back end drives the advertising platforms' APIs (eg Google and Facebook), and it all hooks into great big machine learning operations that run on big beefy servers out in EC2. Not just a pretty CRUD app, that's for sure.
(Unfortunately, they know what their services are worth, so I can't just point you at a live demo ;) )
So, the UI/front0end of their app was created with and runs on Anvil, but the backend is entirely under their control? That's interesting. Very interesting.
Their backend is partially inside, partially outside Anvil (eg I believe the campaign management backend runs in our hosted server modules, but the compute-intensive machine learning is offloaded). And it's all under their control - it's their code!
The wonderful thing about the Uplink is that the boundary between "inside Anvil" and "outside Anvil" can be very fuzzy, because you use the same APIs. (See my "escape hatch" post above)
Awesome! I work at Mendix where we've been building something similar for just over 11 years now. Companies in this space (rapid app development for the web) typically target the Enterprise market and are typically not open source, I think that's why they don't get much interest on HN.
The market is heating up though, we are growing fast and our competitors do as well. Moreover, Google (AppMaker) and Microsoft (PowerApps) have entered the race in the last two years.
I can see this as an amazing teaching aid too. You can take away all the learning about tech stacks and platforms and various languages and server config etc. for a while and concentrate on developing the idea and developing a process.
Edit: My son is going to love this when he gets home!
It seems good enough that you could push the prototype live as an MVP.
I am interested if you grow to something to the stage where you want to move off this and onto something more customised, do you have access to be able to properly migrate the DB somewhere else?
As to your second point - yes, that's a common pattern. We see people going "oh, let me just sketch out the UI...well, I'll add a bit of code...oh, look, it's in production and scaling!"
We do have a lot of support for integrating with external systems, so it's easy to gradually move off from (or on to) Anvil. External access to the database is just the start of it :)
Using this as a teaching platform was my first reaction too.
I don't think I would use it for anything production though without an option to export the app (database & source for my app). I would pay the listed monthly subscription fees in a heartbeat. That is a no brainer for the time this appears to save but I have learned the hard way too many times in the past on being locked into a platform for business crucial stuff.
I would be fine even paying a one-time fee of few hundred dollars to be able to export my app if I need to. Simply for the peace of mind of not being locked in if something happens.
In the 90s we had RAD tools like Delphi or Visual Basic which allow you to create simple apps very quickly. I feel that we are missing RAD on the web these days. There are so many different moving pieces. To do a full modern web app you need to learn different languages and frameworks plus other technologies for hosting such as containers or AWS, etc. That might work for complex apps, but sometimes you just want to do something simple that you can easily design visually, use one language and hit one button to publish. I have the feeling that Anvil is moving in this direction.
Went nostalgic. I remember SilverStream. I had made a proposal for a movie theatre booking project around 2000 and had proposed using this. Though the client didn't care, I was very much in to the java hype raging then. (this is India)
Ah the CMS wars of the 2000s. In a David/Goliath kind of thing, we managed to beat them many times when they were one of the offerings. I don't remember why we won usually but probably because we were local and price.
Were you at PyCon UK this weekend? Cause you just repeated our pitch, just about word for word :)
I started out on QBASIC and Visual Basic, back in the day, and as far as I'm concerned it's practically dereliction of duty that there wasn't something similar available for the web. Eventually, we got fed up enough to go and build it ourselves.
I learned to program with Turbo Pascal and then moved to Delphi. While watching your introduction demo my thoughts were "this is like Delphi for the web". I've also missed something like this for a long time.
It is really cool to see someone reviving the RAD concept, especially within the Python ecosystem. I was pretty big into Delphi back in the day--even worked for Borland testing it for a bit. I'm looking forward to trying this out.
Visual Basic where you replace basic with Python is compelling enough. On the web with a visual design editor ? That’s worth more than 50 bucks enough so that you can crank out a prototype.
No one is forcing you to cargo-cult the backend architectures of huge companies. There is no shame in using mod_passenger, mod_wsgi, Elastic Beanstalk, Heroku, etc.
Containers and container schedulers should be employed when it’s harder to not use them, at which point you can afford full-time SREs.
I love this idea. It reminds me a lot of old school .NET worked within Visual Studio, or the Delphi editor for Windows application forms.
.NET has evolved into a totally different beast so I don't use it any more. This framework brings back the simplicity that I feel has been lost from drag and drop tools.
Drag and drop tools exist for the web, but there's nothing that introduces and organises the use of simple programming languages within the mix - at least that I know of - so this is definitely going into my list of cool tools.
Looks very impressive. Any plans of offering this a-la-gitlab: paid hosting + support OR free downloadble source but then you're on your own? Main concern is that for something to really become ubiquitous the community should be able to contribute and not just be in the hands of two developers (no offense, I think you did a fantastic job!)
Also, and exactly because I find it very interesting and well done, I'm curious about what happens if the company goes down, or pivots, or gets acquired.
I share this concern. I made a resolution not to tie myself to proprietary services for anything that I couldn't replace/move within a few days. I can move containers, databases and even serverless functions.
Starting from scratch seems to be the only option here, so I would hesitate to even start a small prototype. Which is a shame because I really like your model.
He just copied and pasted his code from the notebook into an Anvil server function, and it ran first time! It's all just Python, at the end of the day.
Oh yes. I know some people who work with them, and they charge quite a bit of money. They're exactly like Oracle, they'll charge you for every single feature and these are not small amounts. Not to mention the pain you have to deal with once you want to do anything more complicated than their platform provides. I am not aware of anything stories in particular but I can imagine that migrating away from them is not an easy task.
On the other hand, I gotta give it to them that it does some things well. I definitely see it solving problems in industries that need custom software but simply don't have the resources or capital to get a completely custom, from-scratch system.
Absolutely - please ask about our Enterprise plans ;)
That said, even with the standard plans you can plug into your own Postgres database from server code (just `import psycopg` - it's only Python, after all). And using the Uplink, you can access Anvil's database from your code anywhere on the internet, with the same API as Anvil server code.
What you should really do is also sell anvil in a form that makes it possible to host on premise or in AWS or somewhere else. Even if you charge a 1000$for that people would pay up. You don’t need to open source everything but you can sell the compiled c files instead with installations and support guidelines. I would love to use it but if I cannot control the infrastructure I feel my hands are tied.
Installing and running it is typically a single 'docker-compose' command. If you're interested in this option, please do drop us an email at sales@anvil.works.
Also things like bulk uploads to a table for migration, would I have to write a service for this? I have an app I would like to migrate that has a sqlite table with static data in it, that I could see using this. I suppose I could use the server connector, but what other tools does this have?
I fail to see the equivalence. I'm not contracting with Anvil for development or support. I'm basically buying a tool, in this case a tool that is more expensive than my hosting costs.
One, if you're using it commercially, it's going to pay for itself pretty quickly. I rarely do client projects for less than several thousand pounds; I reckon I could probably churn a lot of them out using this in half the time.
Two if you're not using it commercially, it's still a very low cost; maybe more than pure hosting but it does a lot more than just hosting.
Honest question, this looks awesome but how would a contractor justify using it? Would you somehow swallow the risk of them going out of business for whatever reason and promise a rewrite for clients (is that something you can get insured for?) or would clients just be okay with the risk? It seems like you'd have to have already bought enterprise to be able to run this without them from what I can tell?
So I've been working on a python flask web app in part time/spare time for my business for almost two years (in addition to running a company doing several million USD in sales over that time without the app.) In that two years, I've tracked my programming time with wakatime and I'm at >1000hrs now, more than 25 full-time 40hr work weeks of actual coding time. I'm running the app on a dedicated GPU server, as part of the apps function is to evaluate 3D CAD files. Time spent managing and running a dedicated server is not even counted in the 1000hrs. Of course, I've also had to learn to be a Postgres database admin and dozens of support libraries. And, certainly must have at least some javascript/jquery. Libraries like flask-admin and flask-security are great. But, when you need them customized for production, it takes weeks of time to dig in and actually learn how they are built from the inside out. Need to subclass and override much of it to finally have something usable. I literally just spent about a month hacking on flask-security to get the login/email-confirmations/email templates/argon2-hashing/2-factor-auth the way I need it. Then, I watch this video the guy replicates most of the functionality in six minutes. Nice work, definitely looks like heading in right direction.
My personal experience with Flask has led me to believe it's many times easier to expand on vanilla Flask then it is to try and incorporate any of the flask-* libraries.
I ended up with writing my own flask extension that integrates some useful flask-* libraries and client-side JS libraries in very opinionated way. Somewhat ironically I'm currently in process of spliting that into separate flask extensions...
Having just built a boilerplate that integrates a bunch of the flask-* libraries, I think the key really is that you need to be careful about how you organize your code: it's important to be able to control the order of registering the various extensions you're using relative to when you're registering your app code. Otherwise you're going to end up in circular-dependency import hell. Buried in the documentation is a hint on how to do this correctly with application factories[0], but if you don't know that's there, it's very hard to just stumble upon how to correctly organize everything.
Flask never really seemed like a very mature framework to me, it got so many strange inconsistencies and very dubious design choices I much prefer newer, significantly simpler frameworks.
One example is the way the request context works in flask, I venture to say thats just terrible software design in my book (from flask import request, g). And seriously to have your framework give you a "global" variable to put random stuff in, wth?
Also I rather not use Flask-SQLAlchemy since why should my database models be tied so incredibly closely to some library of my web MICRO framework, it doesn't make sense, I mean its not django why introduce this coupling?
It seems if you need all the dependent libraries (like webassets and wtforms) just use django from the get go instead of going through the pain of trying to cleanly integrate dozens of flask libraries.
To see how a proper simple middleware-based framework should look like consider express, koa (nodejs), or bottle, falcon. Aiohttp and tornado also have their place of course.
My personal experience with http is that you parse url and cookies by hand and never bother to use any crap “framework”. Of course, it has to be reverse-proxied with all irrelevant headers cleared, e.g. via nginx, which can also serve /static efficiently and provide https-http conversion. If you’re familiar with Lua, then writing http to json-only or binary-only unix socket is a no brainer in OpenResty, so you can skip backend-side parsing at all.
Flask/etc was useful magic only until I figured out what it really does between me and underlying socket.
I would bet that you would need about the same amount of time nomatter what technology you used. The catch is this sentence:
> I literally just spent about a month hacking on flask-security to get the login/email-confirmations/email templates/argon2-hashing/2-factor-auth the way I need it.
I don't know Anvil but I am sure it has a specific way of dealing with login/signup/... - just like every other framework. And if you want to modify it, well, that takes time. And I am guessing it was the same with other tasks.
There is nothing wrong with that, of course. Just saying. :)
Anvil's built in "Users" service is incredibly simple and un-magical (user records are just database rows, and you can reimplement vanilla password login in four lines). This makes hacking on it an awful lot easier than some magically injected extension that needs to be configured just so.
I went from learning Python with Bottle, moved to Flask, found I was reinventing the wheel with just about everything, wasted vast amounts of time trying to integrate basic functionality from third party Flask libraries for things like auth and cookies, moved on to Falcon for building APIs, and finally arrived at AWS Lambda with Python and Cognito. Its now six years into the journey of turning myself into a complete full stack developer with database, back end and front end skills.
With AWS Lambda, Python, AWS Cognito, Postgres and ReactJS I can build large scale complete applications.
I think I'm vastly more productive today than I was then. That's partly a function of being a much better programmer in general, partly about now having developed expertise with my chosen technology set.
There's no way I'd go back to something as bare bones as Bottle or Flask any more. If I had to use a Python framework I'd look at a batteries included system like Django. As I say however, I've settled on Lambda, Cognito, Python, Postgres and ReactJS. I've done the hard yards... years of learning and many thousands of lines of code written.
>> Need to subclass and override much of it to finally have something usable.
This is really not something you should be spending your minimal available programming time doing.
After having done it a few times I personally don't find Flask auth very time consuming to implement.
But I'll admit I really like Flask. I find it just the right approach between something simple and something that can be much more complex with extensions. I don't like all of the extension (WTF Forms for instance can do without and SQL Alchemy usually is better independent of Flask IMOP) but these don't need to be used. I've stuck with Flask as much as possible over the years and that alone has led to a huge productivity increase for me because of familiarity.
awesome stuff, I never tracked my time but would have done similar hours over 2 years on iOS/Android/Python-Flask & Flask-Security.
Doing a rebuild now I have scaled and have a team and am using Auth0, and thankfully I am grateful for the abstraction!
That's exactly what you can do! If you open up a Server Module, you'll see a drop-down in the top-right. That will allow you to select a Python 3.6 runtime.
The client-side code is Python 2 only for now, but we're already upgrading our Python-to-Javascript compiler to include Python 3 syntax.
Are you looking at Transcrypt https://www.transcrypt.org/ as a replacement for Skulpt at all? Because its here and it already works great for Python 3.6, it just needs more usage to develop workflows and examples around it and tools like Anvil are a great way to get started with any technology.
I will only leave it and never pay if something terrible happens: the price is jacked up, service suffers or I create such a great thing that I need commodity pricing.
But its worse than that: if I don't have the security that I can leave, I won't dedicate time to use this.
I am happy to pay for the convenience and to try to create MVPs or proofs of service etc.
Anyway, it hardly matters what I think. Imagine what all the students and start ups think when they see it.
Customers aren't that black and white. I used to work for a SaaS company, and having the option of requesting the source and copy of the database was crucial to land quite a few of our contracts.
That said, I agree with you that it's probably not their best approach right now. Even if it pains me to say so :)
I don't think being locked down to a service is that important in this case. I see Anvil as a potentially valuable tool to create prototypes, to quickly iterate on an idea... then when it is validated, you can build it with more conventional (and safer in terms of future) tools.
Yes, its funny but I think of python itself as an exceptional good "prototyping" language. Thats not to say it can't be used in production, but I think the real power of python comes from its ability to go from 0-100 in a very short amount of time (powered by all the great python libs).
So in a sense, Anvil is valuable at its price point for just as a web prototyping service. Most new developers obsess on things like "scalability" and "MVC separation", etc and in 95% of cases their creations never ever generate enough traffic to warrant any of that. I see Anvil as a tool that would allow developers to sketch out an idea, quickly iterate features based on feedback, and when warranted, move to a full production stack.
This is not an unreasonable ask though. You should certainly think twice to pigeon holing yourself with any technology that you do not have full rights to and will be lost without a specific provider.
It does make figuring out your business model more complicated, but having SOME story for what will happen if you go out of business or start being a bad actor is something you need to figure out.
It isn't impossible though, our SAAS is Open Source and we survive, though yes, some customers do choose to self host. You just end up with fewer enterprise customers and more smaller clients.
I understand the request, because I would not use the service myself for the same reasons.
But let's be real, if it became open source, I would just host it and never pay for it. They would have to do more work for less money. Hardly fair.
They can always start with a strong commercial offer, then later address the user locking issue. For them, I think it's a way better strategy. FOSS first is very hard to monetize. The Libre community is a terrible customer.
If I make software that enables you to create things, then the software is mine and I can charge you for using it, but what you make using my software is yours and you can do whatever you want with it.
Yes, that's true. But that does describe Rails. A pure Python web framework, integrated, with a python to javascript transpiler is very likely to emerge, but I can say with almost total certainty that it will have to be open source.
I don't know any actual numbers, but I think DHH and basecamp almost certainly profited from the popularity of Rails. That's probably up for grabs, since integrated web environments in non-js languages may become a big deal over the next decade.
DHH and basecamp made money because they are explicitly not open source and you have to pay for it.
The fact they are built with RoR is an implementation details. 37signals was very good at communication, Ror or not. Their blog and books were fantastic.
ROR as a FOSS may have helped, but I doubt it was instrumental.
yes, exactly, they found a way to monetize a product other than their framework, and they used the OSS framework to draw attention to the non os project. Whether that was deliberate or unintentional, I don't know, but it certainly worked out.
EDIT: I agree with you that the product is good, and that the communication was excellent, but I disagree that the success of ROR was minor to the success of that company. It brought a tremendous amount of attention.
From the website, it looks like you can clone the git repo locally, so you would have the code. Now what I want to know through is if that repo contains all the "magic" code that anvil does. You have to upgrade to PRO in order to clone a git repo unfortunately.
I played with Anvil for the first time at PyConUK last weekend, and I was really impressed.
Specifically on the point of accessing your code:
- if you Architect your code well enough you can keep reasonable separation between generic Python code and code that is tightly-coupled to Anvil (I.e. keep it modular)
- and Anvil does actually provide a means for you to directly clone your Anvil app code locally from their servers using Git. This would give you a copy of all your code including front end templates etc.
I think tie-in is always a consideration but we are increasingly getting into that situation with things like AWS, and so we really must balance the pros and cons. I’d rather by tied in and profitable if I’m trying to get something off the ground...
This looks amazing (speaking as an old Delphi programmer).
My three questions:
- I have a client whose app sits idle but then gets hit by maybe 300 concurrent users, all reading and writing within a few seconds of each other - do you have anything in place to deal with that kind of spike in usage?
- It looks like it's designed to be always online - any plans to make it offline-and-sync capable?
- Any documentation or hints on automated testing?
206 comments
[ 4.1 ms ] story [ 157 ms ] threadOn-site installation
For when you need to keep sensitive data or apps inside your firewall. Anvil on-site installations allow you to develop and deploy your apps entirely in-house.
Urk? Firefox is an officially supported platform for the editor. What didn't work, and what version of FF are you using?
Once you've written an app, it should work in everything since IE11.
We've now been in touch by email about this bug, and we'll make sure a fix is pushed ASAP!
https://anvilformac.com/
I’m excited to try the Python-based Anvil for quickly prototyping interactions to share with my product and dev teams.
Edit: Typo!
* Front-end code is compiled from Python to JS with Skulpt (http://skulpt.org)
* The back-end code runs in a custom Python sandbox. Calls to server functions go over a secure web socket (this lets us do fun things like returning database rows directly from server functions, rather than faffing with REST APIs all day)
* The built-in database (Data Tables) is based on Postgres, using its JSONB and GIN indexing to create a table you can search efficiently on any column. This also means that things like transactions are properly robust.
(Right now, it does run in the browser, but we'll be moving it to the back-end soon to improve performance. For now it's good enough.)
From the Skulpt website: "Skulpt is an entirely in-browser implementation of Python."
It sounds like you implemented python in JS, so there is no compilation to JS. The application code is always python and is evaluated on the client, no?
If you move it to the back end, would that not be something like Trascrypt?
Skulpt has a separate compiler stage that compiles Python to JS, and a runtime library. There's no need to eval() that code in the same JS VM that compiled it, so it's totally feasible to ship the JS to the client and run it there.
We also have a bunch of tutorial-cum-demo videos at: https://anvil.works/learn#tutorials
Or are you worried about clones?
I'd also discourage a patreon- or kickstarter-style offering for a B2B product, because it signals very clearly that you're not playing with the big fish.
As for signaling, one would not have to use those providers if they felt it did not fit their brand, and could roll their own platform. But if signaling that you want to "play with the big fish" is what one wants, most companies hire sales team who go out and play golf with prospects. Having an open source product and using other forms of funding certainly does not preclude doing that. (Though being a small bootstrapped business might make it more difficult).
While charging for use might seem like a good business model, I think an awful lot of potential customers will just never use it because of it. You may be able to find a model where you charge for the front-end page designer or something, but open source everything needed to run the site so that being locked in to a product you have to pay for and can't modify is less of a concern.
Right now we're taking it all as it comes, but we never want to lose our focus on accessibility: It's way too hard to build web apps with today's traditional tools, and we want to make it easier for everyone.
You might be interested in my talk from PyCon US this summer, where I talked about the compiler, and how we turn blocking Python code into non-blocking Javascript code:
https://anvil.works/blog/pycon-talk
I'm really not a fan of Python client side. Or RAD. Or closed source services.
And I'm hugely impressed by the potential of your product.
Good luck.
I never though I would say that one day. But don't listen to people asking you to open sourcing it now. You can always do it once you are profitable. But right now, you need money to get this going. And if your product does what you say it does, people will be happy to pay.
Although not to be locked up on the long run. You will need to address that one day. One day.
I want to second that, entirely.
Don't do it until you are comfortable.
My only suggestion is if you are closing the product for any reason, then open source the core as much as possible.
Being a penny pinching student, do you guys offer any discounts for students?
My question is about scaling - what are some large apps on this platform and how big do you think these apps can get in terms of db size and qps?
Our infrastructure is all on AWS and designed to scale horizontally, so we're pretty confident we can handle whatever traffic you throw at your app. (Ask about our dedicated-resource hosting plans!)
As for examples, it's a bit Catch-22. Our smaller customers, you haven't heard of; and our largest ones, we can't talk about in public. And a lot of it is internal/intranet stuff anyway.
One customer has kindly allowed us to talk a bit about their app - see https://news.ycombinator.com/item?id=15589020
I just had a video demo tutorial with your colleague @daviesian. He is such an intelligent and effective communicator. I learned a lot about your platform in a short 30-minute screen sharing.
In the crowded world of PaaS, human factors might have equal (if not more) importance than the technology magic. From my experience with Ian, I do see the bright future of your platform. You have a great team that people will trust.
Keep up the good work!
Their pricing page doesn't show anything about usage limits and if it is "per site" or "per domain" or "per project".
Usage limits are pretty soft right now (depends heavily on what you do in your code and how hard you're hammering our servers), but the general intention is to charge you more as you scale up your team, rather than because you got a few thousand users.
My issue is if being used for websites, on average our sites get ~50k visitors a month or even spikes with that amount.
The same goes for complexity of the system, for simple html sites it will not matter much but for very dynamic apps this will require a lot of CPU time.
[heads over now]
So if we build something that becomes wildly successful, we could suddenly be in a world of hurt if our site is deemed too heavy and we're throttled or worse. It would be like Pokemon Go - big explosion, lots of tiny pieces, customers gone.
I urge you to have some kind of professional plan with guaranteed tiers. Otherwise, only naive people or people who really don't care about the future will use it (outside of the prototyping case everyone else is mentioning).
On the other hand, it would be the perfect tool for someone on upwork or the like to do a gig ultra fast, leaving the client to deal with all the future pains. But since most projects end up not huge and successful, that might be just fine!
We're starting to post some larger examples (check out our "download portal" example at https://anvil.works/learn#examples - I'm also working on a video series building a SaaS app over the course of a few hours). But the biggest apps are, of course, our customers', and we can't really publish them as examples.
Their control panel drives companies' entire online marketing operation - creative, targeting, performance, and more - across multiple advertising services. That's a whole lotta UI. Their back end drives the advertising platforms' APIs (eg Google and Facebook), and it all hooks into great big machine learning operations that run on big beefy servers out in EC2. Not just a pretty CRUD app, that's for sure.
(Unfortunately, they know what their services are worth, so I can't just point you at a live demo ;) )
The wonderful thing about the Uplink is that the boundary between "inside Anvil" and "outside Anvil" can be very fuzzy, because you use the same APIs. (See my "escape hatch" post above)
The market is heating up though, we are growing fast and our competitors do as well. Moreover, Google (AppMaker) and Microsoft (PowerApps) have entered the race in the last two years.
Looking forward to seeing more of Anvil.
Edit: My son is going to love this when he gets home!
It seems good enough that you could push the prototype live as an MVP.
I am interested if you grow to something to the stage where you want to move off this and onto something more customised, do you have access to be able to properly migrate the DB somewhere else?
https://twitter.com/anvil_works/status/924648315983155200
As to your second point - yes, that's a common pattern. We see people going "oh, let me just sketch out the UI...well, I'll add a bit of code...oh, look, it's in production and scaling!"
We do have a lot of support for integrating with external systems, so it's easy to gradually move off from (or on to) Anvil. External access to the database is just the start of it :)
I don't think I would use it for anything production though without an option to export the app (database & source for my app). I would pay the listed monthly subscription fees in a heartbeat. That is a no brainer for the time this appears to save but I have learned the hard way too many times in the past on being locked into a platform for business crucial stuff.
I would be fine even paying a one-time fee of few hundred dollars to be able to export my app if I need to. Simply for the peace of mind of not being locked in if something happens.
In the 90s we had RAD tools like Delphi or Visual Basic which allow you to create simple apps very quickly. I feel that we are missing RAD on the web these days. There are so many different moving pieces. To do a full modern web app you need to learn different languages and frameworks plus other technologies for hosting such as containers or AWS, etc. That might work for complex apps, but sometimes you just want to do something simple that you can easily design visually, use one language and hit one button to publish. I have the feeling that Anvil is moving in this direction.
And extra love for using Python :D
http://www2.sys-con.com/itsg/virtualcd/java/archives/0403/be...
I started out on QBASIC and Visual Basic, back in the day, and as far as I'm concerned it's practically dereliction of duty that there wasn't something similar available for the web. Eventually, we got fed up enough to go and build it ourselves.
I learned to program with Turbo Pascal and then moved to Delphi. While watching your introduction demo my thoughts were "this is like Delphi for the web". I've also missed something like this for a long time.
I'm definitely going to try your product!
You can control which columns do and don't collapse on mobile or tablets. See this post from our user forum: https://anvil.works/forum/t/how-do-i-make-my-apps-look-nice-...
Happy Pythoning :)
Containers and container schedulers should be employed when it’s harder to not use them, at which point you can afford full-time SREs.
.NET has evolved into a totally different beast so I don't use it any more. This framework brings back the simplicity that I feel has been lost from drag and drop tools.
Drag and drop tools exist for the web, but there's nothing that introduces and organises the use of simple programming languages within the mix - at least that I know of - so this is definitely going into my list of cool tools.
Starting from scratch seems to be the only option here, so I would hesitate to even start a small prototype. Which is a shame because I really like your model.
https://twitter.com/anvil_works/status/924352019258920960
He just copied and pasted his code from the notebook into an Anvil server function, and it ran first time! It's all just Python, at the end of the day.
On the other hand, I gotta give it to them that it does some things well. I definitely see it solving problems in industries that need custom software but simply don't have the resources or capital to get a completely custom, from-scratch system.
That said, even with the standard plans you can plug into your own Postgres database from server code (just `import psycopg` - it's only Python, after all). And using the Uplink, you can access Anvil's database from your code anywhere on the internet, with the same API as Anvil server code.
Installing and running it is typically a single 'docker-compose' command. If you're interested in this option, please do drop us an email at sales@anvil.works.
Also things like bulk uploads to a table for migration, would I have to write a service for this? I have an app I would like to migrate that has a sqlite table with static data in it, that I could see using this. I suppose I could use the server connector, but what other tools does this have?
One, if you're using it commercially, it's going to pay for itself pretty quickly. I rarely do client projects for less than several thousand pounds; I reckon I could probably churn a lot of them out using this in half the time.
Two if you're not using it commercially, it's still a very low cost; maybe more than pure hosting but it does a lot more than just hosting.
I’m always upfront about the tools I use with my clients as the value isn’t in the tool, it’s in their requirements.
But being able to move away quickly is important to me because I have client relationships (and production code) that is 9 years old.
(I also don’t consider myself a contractor, more a consultant - a semantic difference but an important one)
Our consulting rates are way above that per week.
[0] http://flask.pocoo.org/docs/0.12/patterns/appfactories/
One example is the way the request context works in flask, I venture to say thats just terrible software design in my book (from flask import request, g). And seriously to have your framework give you a "global" variable to put random stuff in, wth?
Also I rather not use Flask-SQLAlchemy since why should my database models be tied so incredibly closely to some library of my web MICRO framework, it doesn't make sense, I mean its not django why introduce this coupling?
It seems if you need all the dependent libraries (like webassets and wtforms) just use django from the get go instead of going through the pain of trying to cleanly integrate dozens of flask libraries.
To see how a proper simple middleware-based framework should look like consider express, koa (nodejs), or bottle, falcon. Aiohttp and tornado also have their place of course.
Flask/etc was useful magic only until I figured out what it really does between me and underlying socket.
> I literally just spent about a month hacking on flask-security to get the login/email-confirmations/email templates/argon2-hashing/2-factor-auth the way I need it.
I don't know Anvil but I am sure it has a specific way of dealing with login/signup/... - just like every other framework. And if you want to modify it, well, that takes time. And I am guessing it was the same with other tasks.
There is nothing wrong with that, of course. Just saying. :)
Anvil's built in "Users" service is incredibly simple and un-magical (user records are just database rows, and you can reimplement vanilla password login in four lines). This makes hacking on it an awful lot easier than some magically injected extension that needs to be configured just so.
(Check out the API: https://anvil.works/doc#users)
With AWS Lambda, Python, AWS Cognito, Postgres and ReactJS I can build large scale complete applications.
I think I'm vastly more productive today than I was then. That's partly a function of being a much better programmer in general, partly about now having developed expertise with my chosen technology set.
There's no way I'd go back to something as bare bones as Bottle or Flask any more. If I had to use a Python framework I'd look at a batteries included system like Django. As I say however, I've settled on Lambda, Cognito, Python, Postgres and ReactJS. I've done the hard yards... years of learning and many thousands of lines of code written.
>> Need to subclass and override much of it to finally have something usable.
This is really not something you should be spending your minimal available programming time doing.
After having done it a few times I personally don't find Flask auth very time consuming to implement.
But I'll admit I really like Flask. I find it just the right approach between something simple and something that can be much more complex with extensions. I don't like all of the extension (WTF Forms for instance can do without and SQL Alchemy usually is better independent of Flask IMOP) but these don't need to be used. I've stuck with Flask as much as possible over the years and that alone has led to a huge productivity increase for me because of familiarity.
However, we run full CPython (2.7 and 3.6) on the server, so any language feature you like is just a function call away :)
As Py2 is EOL in about two years it feels risky for anything to be built on it.
The client-side code is Python 2 only for now, but we're already upgrading our Python-to-Javascript compiler to include Python 3 syntax.
1. Great idea, just what "we" need in the language we need. (Python cloud RAD).
2. But I don't want to do all this work and be locked into your system forever. I want to be able to run this on Digital Ocean or AWS etc. if I want.
I think am open source version where you give people an option of hosting on your site at first would be the best compromise. Please consider it.
But its worse than that: if I don't have the security that I can leave, I won't dedicate time to use this.
I am happy to pay for the convenience and to try to create MVPs or proofs of service etc.
Anyway, it hardly matters what I think. Imagine what all the students and start ups think when they see it.
If you want control, you don't use a closed source saas RAD.
I would not use the product for myself. I would hate been locked down.
But I can see the value for others. For some, having one easy but clear solution is the important value.
That said, I agree with you that it's probably not their best approach right now. Even if it pains me to say so :)
So in a sense, Anvil is valuable at its price point for just as a web prototyping service. Most new developers obsess on things like "scalability" and "MVC separation", etc and in 95% of cases their creations never ever generate enough traffic to warrant any of that. I see Anvil as a tool that would allow developers to sketch out an idea, quickly iterate features based on feedback, and when warranted, move to a full production stack.
It does make figuring out your business model more complicated, but having SOME story for what will happen if you go out of business or start being a bad actor is something you need to figure out.
It isn't impossible though, our SAAS is Open Source and we survive, though yes, some customers do choose to self host. You just end up with fewer enterprise customers and more smaller clients.
But let's be real, if it became open source, I would just host it and never pay for it. They would have to do more work for less money. Hardly fair.
They can always start with a strong commercial offer, then later address the user locking issue. For them, I think it's a way better strategy. FOSS first is very hard to monetize. The Libre community is a terrible customer.
Doing it the other way around is wrong.
I don't know any actual numbers, but I think DHH and basecamp almost certainly profited from the popularity of Rails. That's probably up for grabs, since integrated web environments in non-js languages may become a big deal over the next decade.
The fact they are built with RoR is an implementation details. 37signals was very good at communication, Ror or not. Their blog and books were fantastic.
ROR as a FOSS may have helped, but I doubt it was instrumental.
EDIT: I agree with you that the product is good, and that the communication was excellent, but I disagree that the success of ROR was minor to the success of that company. It brought a tremendous amount of attention.
Specifically on the point of accessing your code:
- if you Architect your code well enough you can keep reasonable separation between generic Python code and code that is tightly-coupled to Anvil (I.e. keep it modular)
- and Anvil does actually provide a means for you to directly clone your Anvil app code locally from their servers using Git. This would give you a copy of all your code including front end templates etc.
I think tie-in is always a consideration but we are increasingly getting into that situation with things like AWS, and so we really must balance the pros and cons. I’d rather by tied in and profitable if I’m trying to get something off the ground...
My three questions:
- I have a client whose app sits idle but then gets hit by maybe 300 concurrent users, all reading and writing within a few seconds of each other - do you have anything in place to deal with that kind of spike in usage?
- It looks like it's designed to be always online - any plans to make it offline-and-sync capable?
- Any documentation or hints on automated testing?