WebScript.io: Just choose a URL and type in a script. No servers, no deployment(webscript.io)
webscript.io
WebScript.io: Just choose a URL and type in a script. No servers, no deployment
https://www.webscript.io/?
22 comments
The first thing I thought was also 'What language can I script in?' After a few clicks I just closed the tab. Should definitely be more visible.
*Lua
I'd like to add my +1 to this, I felt pretty much all of those sentiments.
* "Webscript brings the simplicity and power of scripting to the web" Isn't that javascript?
* Oh I see, it's a server side language. But... this just sounds like a backend language for Getting Shit Done. Which I don't disagree with, but-- oh, can you excuse me a moment while I answer the doorbell? "Oh hi Perl, hi Node, come on in..."
* I personally do say I'm unlikely to use it because it's not instantly clear to me. I'm a sysadmin by trade so I don't think I'm the target audience, but I couldn't immediately tell what I'm meant to use webscripts for.
* I hate hate HATE watching videos. I'm sure this is a very personal thing and maybe I'm the 0.1%, but I always feel like videos are a waste of my time, or simply not the best way to communicate the message. We work with keyboards to write scripts, why would I want to see a video of that?
Okay, so I watched the first 20sec of the video. That gave me the "Aha!" moment. The first thing I thought of was the way you used to have CGI hosting servers, back in the pre-PHP days, because the majority of websites were completely static.
I don't mean to come off as mean or aggressive, but I really had trouble answering the most important question (to me): What problem is Webscripts going to solve for me? That's it.
* "Webscript brings the simplicity and power of scripting to the web" Isn't that javascript?
* Oh I see, it's a server side language. But... this just sounds like a backend language for Getting Shit Done. Which I don't disagree with, but-- oh, can you excuse me a moment while I answer the doorbell? "Oh hi Perl, hi Node, come on in..."
* I personally do say I'm unlikely to use it because it's not instantly clear to me. I'm a sysadmin by trade so I don't think I'm the target audience, but I couldn't immediately tell what I'm meant to use webscripts for.
* I hate hate HATE watching videos. I'm sure this is a very personal thing and maybe I'm the 0.1%, but I always feel like videos are a waste of my time, or simply not the best way to communicate the message. We work with keyboards to write scripts, why would I want to see a video of that?
Okay, so I watched the first 20sec of the video. That gave me the "Aha!" moment. The first thing I thought of was the way you used to have CGI hosting servers, back in the pre-PHP days, because the majority of websites were completely static.
I don't mean to come off as mean or aggressive, but I really had trouble answering the most important question (to me): What problem is Webscripts going to solve for me? That's it.
Hmm. First thing I did was hit Examples then start messing around with Demo and I understood immediately what was happening.
They should probably emphasize this approach IMO
They should probably emphasize this approach IMO
I'm one of Webscript's founders, and I was pleasantly surprised to see this here. We just launched this morning, and I'm happy to answer any questions.
I'm going to channel my inner patio11:
* Charge whole numbers, not 4.95. No need for the confusion. Makes the service look cheap.
* Double or triple the price (to $10-15/month). $5 vs $10 is nothing to the average dev, but it halves the number of people you need to get to ramen profitable.
* Have an expensive pro plan ($99 - $299/month). With email support, etc. If nothing else, it makes the less expensive plans more attractive.
* Don't "delete" the free scripts. "Archive" them after 7 days [it's a 7-day free trial] and you can get them all back when you upgrade to pro. If someone wants to "abuse" the system by recreating their scripts every 7 days, fine.
99% of devs will be more familiar with javascript than Lua, so I'd greatly encourage supporting that.
* Charge whole numbers, not 4.95. No need for the confusion. Makes the service look cheap.
* Double or triple the price (to $10-15/month). $5 vs $10 is nothing to the average dev, but it halves the number of people you need to get to ramen profitable.
* Have an expensive pro plan ($99 - $299/month). With email support, etc. If nothing else, it makes the less expensive plans more attractive.
* Don't "delete" the free scripts. "Archive" them after 7 days [it's a 7-day free trial] and you can get them all back when you upgrade to pro. If someone wants to "abuse" the system by recreating their scripts every 7 days, fine.
99% of devs will be more familiar with javascript than Lua, so I'd greatly encourage supporting that.
I am in agreement about the inclusion of JS. It's a much more widespread and accessible language. However, I disagree on the price suggestion. $15 is a non-trivial amount and, it seems as though this service offers a slight convenience, not any sort of major, unique or ground-breaking functionality. I might pay $5 for this– or, maybe not– but I almost certainly won't pay $15 for such a service. (I might be in the minority as to how much I'd be willing to spend for this, especially considering I'm in dire financial straits. Despite that, I still feel as though $15 would exceed the amount of value that most people could reasonably wring from this service.)
I genuinely dislike their pricing model. I'm of the belief that, if one elects to offer a free tier, that tier should be usable in the real world. I should be able to write something that makes use of that service. This one-week "time bomb" precludes any real application of the service, and effectively makes this tier a trial. I agree that deleting the scripts is a bad idea, and is likely to produce a few indignant developers who forgot to either subscribe or re-create their scripts.
I genuinely dislike their pricing model. I'm of the belief that, if one elects to offer a free tier, that tier should be usable in the real world. I should be able to write something that makes use of that service. This one-week "time bomb" precludes any real application of the service, and effectively makes this tier a trial. I agree that deleting the scripts is a bad idea, and is likely to produce a few indignant developers who forgot to either subscribe or re-create their scripts.
* We'd be happy to be proven wrong, but we believe $4.95 converts better than $5.
* We'd be happy to charge more. We have nothing to go on yet but intuition, and we think $5 is the right amount.
* This is intriguing, but I think we need to find the right value to provide in order to offer something like that.
* This is actually what we do.
* We'd be happy to charge more. We have nothing to go on yet but intuition, and we think $5 is the right amount.
* This is intriguing, but I think we need to find the right value to provide in order to offer something like that.
* This is actually what we do.
* No prob :). The beauty of the web is experimentation. Use VisualWebsiteOptimizer.com and run some quick A/B tests with two pricing tables [one at 4.95, another with $5].
* Test that assumption too :). Have table 1 with free/$5, table 2 with "Free trial", $10, $199 [pro]. Track "conversion revenue" not raw conversions.
* Large customers want to know they can get help if they need it, not be stuck in the same email queue as the $5/month hobbyists :). That peace of mind is worth a few hundred a month.
* I see -- your wording on the hover tip says "deleted" (in bold) so easy to misconstrue :). If you said "archived (and reactivated when you upgrade)" I'd feel a lot more comfortable. In my head I thought "Oh, they're deleting my scripts? So I have to decide on day 6 if I want to upgrade?".
patio11's site is full of good advice for this type of thing (http://www.kalzumeus.com/2012/09/21/ramit-sethi-and-patrick-...).
I want you guys to charge more so you are more sustainable, and therefore I can rely on you [if you go away after a year, I have to painfully migrate away to a new provider, which isn't worth the $5/month price savings. An hour of a programmer's time spent in migration, and it'd be much more, is much more expensive than the service].
* Test that assumption too :). Have table 1 with free/$5, table 2 with "Free trial", $10, $199 [pro]. Track "conversion revenue" not raw conversions.
* Large customers want to know they can get help if they need it, not be stuck in the same email queue as the $5/month hobbyists :). That peace of mind is worth a few hundred a month.
* I see -- your wording on the hover tip says "deleted" (in bold) so easy to misconstrue :). If you said "archived (and reactivated when you upgrade)" I'd feel a lot more comfortable. In my head I thought "Oh, they're deleting my scripts? So I have to decide on day 6 if I want to upgrade?".
patio11's site is full of good advice for this type of thing (http://www.kalzumeus.com/2012/09/21/ramit-sethi-and-patrick-...).
I want you guys to charge more so you are more sustainable, and therefore I can rely on you [if you go away after a year, I have to painfully migrate away to a new provider, which isn't worth the $5/month price savings. An hour of a programmer's time spent in migration, and it'd be much more, is much more expensive than the service].
Yeah, but are you testing those beliefs?
Do you have some suggestions for how to test them?
A/B testing. Try something like coupon codes or just two different plans that are presented as "basic plan" (or whatever. Some get plan 1A, some 1B.
What you want to avoid with this sort of AB testing is the same person seeing multiple prices. The easiest, decently close approximation is just to split the page served by geocoded IP. The regions should be split randomly up-front.
Also don't underestimate the value of the more expensive plan to making your $4.95 plan look cheap. A simple answer to what could be premium is contained in your terms: Make the $99/month plan suitable for use in a production environment, as web middleware or a backend, etc by relaxing restrictions and having some sort of SLA.
Also don't underestimate the value of the more expensive plan to making your $4.95 plan look cheap. A simple answer to what could be premium is contained in your terms: Make the $99/month plan suitable for use in a production environment, as web middleware or a backend, etc by relaxing restrictions and having some sort of SLA.
One way to test it is merely to offer larger tiers, in addition to your $5 plan. You may be surprised by your customers' behavior.
$4.95 converts better than $5.
We think $5 is the right amount.
We think $5 is the right amount.
I currently pay $5 per month for a vps with unlimited traffic on which I run a node js server. I might possibly pay 5$ for this service, but certainly no more for applications that aren't going to have >10k users.
Which VPS provider is this?
vpscheap.net They have plans starting from 2$ a month, but I need more RAM than that plan has. I think that $60 per year is exactly right for what I need, and they will let you pay a year up front if you want - it would make an excellent Christmas present for anyone geekily inclined.
[I think they have a referrer program and if you tell them that [email protected] recommended it to you I get something, in case you're feeling generous.]
[I think they have a referrer program and if you tell them that [email protected] recommended it to you I get something, in case you're feeling generous.]
I'm interested in what you are doing here. What is your ideal customer? What should they expect from the platform and what do you expect it to be used for?
-Maybe a potential user who isn't exactly sure what this is doing for me.
-Maybe a potential user who isn't exactly sure what this is doing for me.
How are you sandboxing users, so that they don't mess with your environment?
Most of the sandboxing just comes from using embedded Lua and only whitelisting a small number of functions. We also do a little process-level isolation to prevent runaway processes.
Nice, It would be awesome if one could get full capability of a programming language. I have been planning to build something like this but was stuck because of the sandboxing issue.
You could spawn BSD jails, each subject to cpu, ram and disk quotas.
Agree - wouldn't an infinite loop take down your site?
From the sibling comment: "We also do a little process-level isolation to prevent runaway processes."
Give it a try. :-) We kill runaway processes after 10 seconds.
I think you have made a great choice with Lua! I'd love to see Lua replace PHP at some point in the future as a popular choice for web development.
What makes Webscript better than other BaaS providers that have more advanced functionality available?
http://blog.parse.com/2012/09/11/welcoming-cloud-code-to-the... https://cloudmine.me/docs/servercode
http://blog.parse.com/2012/09/11/welcoming-cloud-code-to-the... https://cloudmine.me/docs/servercode
Hm; to me personally, one advantage is that I immediately understand the idea and usage method of their service, while reading the links you provided I can't grasp what they're trying to communicate, unfortunately.
Also, I know Lua and value it very highly, so seeing it mentioned immediately focused my attention.
Thirdly, "free" "unlimited" "renewable 7-day" trial sounds great, and $5/month for persistent does too.
Also, I know Lua and value it very highly, so seeing it mentioned immediately focused my attention.
Thirdly, "free" "unlimited" "renewable 7-day" trial sounds great, and $5/month for persistent does too.
I agree - the simplicity of the service is great. Can immediately see what it does.
For example do those other services come with storage? I can't tell.
For parse, it looks like you need to install a command line application. Not useful if your desktop is Windoz.
I doubt anyone is going to be building huge applications on webscript.io (yet!) but for simple little things (aka weekend projects) it should work great.
For example do those other services come with storage? I can't tell.
For parse, it looks like you need to install a command line application. Not useful if your desktop is Windoz.
I doubt anyone is going to be building huge applications on webscript.io (yet!) but for simple little things (aka weekend projects) it should work great.
You say time per each script is limited to 10s, yes?
Can I call one webscript from another, for modularisation? And will that "lengthen" the timeout effectively, too?
If yes, then still everything is sequential, there's no possibility of parallelism, yes?
Is there any kind of versioning of the code, apart from the possiblity to load from github you mentioned on the site?
Can I call one webscript from another, for modularisation? And will that "lengthen" the timeout effectively, too?
If yes, then still everything is sequential, there's no possibility of parallelism, yes?
Is there any kind of versioning of the code, apart from the possiblity to load from github you mentioned on the site?
You can make HTTP requests, so you can call another script from your script, but the calls are synchronous and won't increase your timeout, so the original script will still get killed after ten seconds.
No parallelism. What's the use case you have in mind? We didn't really intend for people to do anything CPU-intensive.
No, there's no versioning.
EDIT: s/called/killed, thanks
No parallelism. What's the use case you have in mind? We didn't really intend for people to do anything CPU-intensive.
No, there's no versioning.
EDIT: s/called/killed, thanks
"(...) still get killed (...)" I presume? :)
Nothing particular yet, just assessing the possibilities.
Also, would it be possible to somehow easily download the scripts? In the Terms, you state: "customer is solely responsible for backing up customer's application and customer content." It should be easy to download content from the `storage` object, but how about the code?
Also, it seems I can choose any subdomain for any script, so subdomains are not tied to user by design?
What is the meaning of the following sentence in Terms and Conditions: "Customer has, in the case of Content that includes computer code, accurately categorized and/or described the type, nature, uses and effects of the materials, whether requested to do so by Planet Rational or otherwise." Described/categorized where, to whom, in what categories? What materials?
Nothing particular yet, just assessing the possibilities.
Also, would it be possible to somehow easily download the scripts? In the Terms, you state: "customer is solely responsible for backing up customer's application and customer content." It should be easy to download content from the `storage` object, but how about the code?
Also, it seems I can choose any subdomain for any script, so subdomains are not tied to user by design?
What is the meaning of the following sentence in Terms and Conditions: "Customer has, in the case of Content that includes computer code, accurately categorized and/or described the type, nature, uses and effects of the materials, whether requested to do so by Planet Rational or otherwise." Described/categorized where, to whom, in what categories? What materials?
Yup, I meant "killed." (Edited, thanks.)
We figure that copy/paste is a good enough way to get your scripts out, but if there's demand, it wouldn't be too hard for us to build an export.
Once you create a subdomain, you own it, but you can have whichever ones you choose. (There's no overall subdomain for a user... a user can have as many subdomains as he/she wants.)
A lawyer wrote the Terms, not me, and I probably shouldn't try to interpret them. If you want to discuss it, send us email ([email protected]) and we'll help.
We figure that copy/paste is a good enough way to get your scripts out, but if there's demand, it wouldn't be too hard for us to build an export.
Once you create a subdomain, you own it, but you can have whichever ones you choose. (There's no overall subdomain for a user... a user can have as many subdomains as he/she wants.)
A lawyer wrote the Terms, not me, and I probably shouldn't try to interpret them. If you want to discuss it, send us email ([email protected]) and we'll help.
You just launched today? The site has a lot of functionality already! I'm really impressed.
Were you guys inspired by AppJet at all? I'd love to see JavaScript support.
I loved AppJet, and yes, I'd call it an inspiration for what we're doing.
A number of people are mentioning JavaScript. We don't have any plans yet, but we're paying attention to the feedback.
A number of people are mentioning JavaScript. We don't have any plans yet, but we're paying attention to the feedback.
Amazing! I just want to add my vote for javascript support. I am already invested in javascript for client and server development that having a javascript scripting engine like this would be heaven. Again, great job!
Please stop saying "no servers". Obviously there is a server involved for the script to run on.
That was what caught my attention - I thought it was running locally in the clients browser or something. Peer-to-peer browser-based apps?!
[deleted](1)
Have you tried experimenting with LuaJIT? If yes, what were the results?
Just a few thoughts:
- Certainly easier to use than https://script.google.com
- How about a UI for inspecting the storage object? And why is "storage" _not_ JSON serializable?
- The whole thing gives the impression of "for disposable, not-very-important stuff". Is that deliberate?
- Specifying all the API keys and passwords for each call to an external service by hand seems a bit tedious. Automate all the things! (Maybe with a "secure" credentials object that can be filled with a separate UI?)
- Creating a new script under an existing domain deserves a dedicated UI element, it was not obvious to me that it is possible at all, at first.
- Certainly easier to use than https://script.google.com
- How about a UI for inspecting the storage object? And why is "storage" _not_ JSON serializable?
- The whole thing gives the impression of "for disposable, not-very-important stuff". Is that deliberate?
- Specifying all the API keys and passwords for each call to an external service by hand seems a bit tedious. Automate all the things! (Maybe with a "secure" credentials object that can be filled with a separate UI?)
- Creating a new script under an existing domain deserves a dedicated UI element, it was not obvious to me that it is possible at all, at first.
There is actually UI for inspecting storage. As long as you have no more than 20 keys stored, it shows up on the left-hand side of the page, but you have to refresh the page to get the latest. My excuse for this not being discoverable and automatic: we just launched today. :-)
I'd say we're generally for quick-and-dirty, not necessarily disposable or even not-very-important. But I may be splitting hairs here.
We've been thinking a bit about a sort of global store for credentials. I'm curious to see what people end up doing with Webscript and how often they're typing the same credentials into multiple scripts.
Thanks for pointing out the non-obviousness of creating new scripts in the same subdomain. We'll take a look.
I'd say we're generally for quick-and-dirty, not necessarily disposable or even not-very-important. But I may be splitting hairs here.
We've been thinking a bit about a sort of global store for credentials. I'm curious to see what people end up doing with Webscript and how often they're typing the same credentials into multiple scripts.
Thanks for pointing out the non-obviousness of creating new scripts in the same subdomain. We'll take a look.
The syntax highlighting in the script field is lovely. A question and an issue:
1. What support have you for Unicode? This is Lua's Achilles heel.
2. There's an issue with json.stringify - the script
1. What support have you for Unicode? This is Lua's Achilles heel.
2. There's an issue with json.stringify - the script
t={11, ["1"]=11}
return json.stringify(t)
{"1": 11, "1": 11}
Thanks. We don't do anything special to help or hinder Lua's handling of Unicode. In general, Lua strings store bytes. This is handy when dealing with something like file uploads, but it's not always what you want for other text encodings. If you have any suggestions for what we should do (or what we should document), I'd love to hear them.
Interesting point about json.stringify. We should take a harder look at these kinds of cases. What would you expect the output to be? In general, JSON can't represent a lot of things that Lua tables can, so I don't expect json.parse(json.stringify(T)) to always return T. That said, anywhere we can do something more sensible, we should, so thanks for this feedback (and tell us more).
Interesting point about json.stringify. We should take a harder look at these kinds of cases. What would you expect the output to be? In general, JSON can't represent a lot of things that Lua tables can, so I don't expect json.parse(json.stringify(T)) to always return T. That said, anywhere we can do something more sensible, we should, so thanks for this feedback (and tell us more).
Unicode: I wish I could say "the right way to handle Unicode in Lua is to X", but I haven't found X yet. slunicode at least allows you to do string matching on UTF8 strings: http://files.luaforge.net/releases/sln/
json.stringify: I suggest escaping strings by some character that cannot occur in identifiers or numbers, e.g., ":". Then the above would map to { "1" = 11, ":1" = 11}.
Another question: does your mail function send mail from your server? How do you avoid users sending spam?
json.stringify: I suggest escaping strings by some character that cannot occur in identifiers or numbers, e.g., ":". Then the above would map to { "1" = 11, ":1" = 11}.
Another question: does your mail function send mail from your server? How do you avoid users sending spam?
I'm confused about your stringify suggestion... I think the primary use of json.stringify is to send that JSON to some API or back to a browser, but nobody else would be able to make sense of the ":1". Am I misunderstanding?
We don't run an SMTP server, so the email (port 25 traffic) comes from our servers but not from our SMTP server. Even still, we will probably have to limit port 25 use to avoid blacklisting. We're sorting that out.
We don't run an SMTP server, so the email (port 25 traffic) comes from our servers but not from our SMTP server. Even still, we will probably have to limit port 25 use to avoid blacklisting. We're sorting that out.
OK, but who will make sense of encoding the array {2,3,5} by the object {"1"=2, "2"=3, "3"=5}? Shouldn't you be trying to represent arrays by arrays?
How about representing Lua tables by arrays with an object in position 0? Then { 11, ["11']=11} would map to [{"11"=11}, 11]. The extra layer of depth is annoying, but the semantics is closer to what you want and you avoid collisions between strings and array indices.
How about representing Lua tables by arrays with an object in position 0? Then { 11, ["11']=11} would map to [{"11"=11}, 11]. The extra layer of depth is annoying, but the semantics is closer to what you want and you avoid collisions between strings and array indices.
I'm not sure what you mean. json.stringify {2,3,5} == '[2, 3, 5]', which is correct, isn't it? (Strictly, JSON has to always have a dictionary on the outside, but it's fairly standard to allow this.)
We'll keep thinking about this, but I don't think it's sensible to try to encode {11, ["11"]=11} at all. That's neither an array nor a dictionary, and so it doesn't have a natural JSON representation. I'm inclined to make it an error, but right now we try to be generous in attempting to encode.
We'll keep thinking about this, but I don't think it's sensible to try to encode {11, ["11"]=11} at all. That's neither an array nor a dictionary, and so it doesn't have a natural JSON representation. I'm inclined to make it an error, but right now we try to be generous in attempting to encode.
I had misunderstood the semantics of json.stringify - I thought tables always mapped onto dictionary objects, even if they were arrays. The semantics I suggested is an invertible way of handling that, though the inverse will be odd for JSON arrays whose 0th element is a dictionary object.
Flagging errors in cases with seems to be a good way to handle this kind of problematic input. It's surely better than having applications have nonsensical data if they are given peculiar input.
Flagging errors in cases with seems to be a good way to handle this kind of problematic input. It's surely better than having applications have nonsensical data if they are given peculiar input.
JSON does not have to have a dictionary at the root. You can have just an array.
Looks like you're right. From http://www.ietf.org/rfc/rfc4627.txt:
"A JSON text is a serialized object or array."
Now I don't know why I thought this wasn't allowed.
"A JSON text is a serialized object or array."
Now I don't know why I thought this wasn't allowed.
I'm unfamiliar with Lua, what should it return instead?
4.95 for "unlimited" traffic? So if my script is taking in 100,000 reqs/day I'm still paying 4.95 per month? What about cpu usage, memory consumption?
This is what I want to ask. A fiver per month for all that unlimited seems too good to be true.
Our Terms (https://www.webscript.io/terms) do spend a little time defining "unlimited." We didn't want people to worry about it, so we went with unlimited, but as you point out "unlimited" is always a lie when finite resources are involved.
Our goal is to never have to cut someone off for what seems like legitimate use.
Our goal is to never have to cut someone off for what seems like legitimate use.
> Our goal is to never have to cut someone off for what seems like legitimate use.
In that case, can I recommend that you determine what your costs will be and ensure that you charge, at each tier of usage, enough that you will be able to continue providing your service at a profit to these large-scale users?
In that case, can I recommend that you determine what your costs will be and ensure that you charge, at each tier of usage, enough that you will be able to continue providing your service at a profit to these large-scale users?
(Sorry, can't reply to the real comment, too nested.)
@aaronblohowiak, just because we reserve the right to shut something down doesn't mean that we will.
We'll learn from real use what people actually do. We have our own ideas about what we expect the use cases to be, but we may be completely surprised by the popular uses. If our pricing model doesn't make sense for what people want to do with Webscript, we'll certainly adjust. Thanks for the feedback.
@aaronblohowiak, just because we reserve the right to shut something down doesn't mean that we will.
We'll learn from real use what people actually do. We have our own ideas about what we expect the use cases to be, but we may be completely surprised by the popular uses. If our pricing model doesn't make sense for what people want to do with Webscript, we'll certainly adjust. Thanks for the feedback.
>in excess of 1000 key/value pairs
Tiny! You should have tiers, and not "unlimited, but only where that means enough for a small amount of single-users"
Tiny! You should have tiers, and not "unlimited, but only where that means enough for a small amount of single-users"
Very cool! I can definitely see this being useful.
Out of curiosity, what encouraged you to choose Lua instead of JavaScript or another server-side language?
Out of curiosity, what encouraged you to choose Lua instead of JavaScript or another server-side language?
We probably need to write a FAQ for this. Until then, the short answer is that Lua is well-designed and well-understood as an embedded language (how we use it). That means it was easy and fast for us to integrate.
If we get a lot of feedback about it, we can definitely change course on this later by adding JavaScript and/or other languages.
If we get a lot of feedback about it, we can definitely change course on this later by adding JavaScript and/or other languages.
I haven't ever used Lua, but I think it's simple and easy enough to pick up and learn quickly, so personally it doesn't bother me at all. I'll definitely be using this service when I have the need for it.
On the homepage, there is an example of an incrementing counter. Is this actually an atomic operation, or if two users hit the button at the same time, will it potentially only increase the count by 1?
Great catch! This should properly be implemented using leases:
lease.acquire('count')
local count = storage.count or 0
storage.count = count + 1
lease.release('count')
return {count=count}
Is it fair to call this a similar service to Zapier that runs at a lower level of abstraction?
This appeals to me, because I find its much easier to express myself in code. Zapier is awesome because it makes it so non-programmers can link apps up, but as a programmer I'd rather work in pseudocode* like this instead, and this still keeps me from having to run cron jobs or respond to API changes.
Very cool!
*I realize its Lua, but I mean pseudocode to where I can just say twilio.sms and that magically happens.
This appeals to me, because I find its much easier to express myself in code. Zapier is awesome because it makes it so non-programmers can link apps up, but as a programmer I'd rather work in pseudocode* like this instead, and this still keeps me from having to run cron jobs or respond to API changes.
Very cool!
*I realize its Lua, but I mean pseudocode to where I can just say twilio.sms and that magically happens.
I think that's a great way to think of it!
(I'm a founder of Webscript.)
(I'm a founder of Webscript.)
This looks like a really, really fun project. Great idea.
I like it, great idea! I was really surprised about Lua's choice rather than Javascript since it's all web-based. I'll definitely give it a try.
I would imagine that Lua was much, much simpler to pick apart and integrate into a system like this (from my experience using Lua) than trying to use a full JavaScript engine. A full JavaScript engine would be less lightweight, harder to implement and maybe even harder for end users. That's just my conjecture, anyway ;)
Can i make a webscript that recreates all the other webscripts in my accounts to get around the free 7-day limitation? :)
I'm not a fan of the pricing model - deleting user data after a period of time is a bit harsh in any circumstance, but I don't see an alternative. I'd say cap the number per account, but then you can get multiple account abuse issues.
$5/mo is cheap enough to warrant an impulse purchase, though. Good on you guys.
$5/mo is cheap enough to warrant an impulse purchase, though. Good on you guys.
The fact that Lua isn't very much used will get you less users. I feel like something like JavaScript would've been more appropriate for this kind of thing.
Maybe you should allow different languages? Lua is quite similar to JS, so you can probably port the same API to it, or other languages?
Maybe you should allow different languages? Lua is quite similar to JS, so you can probably port the same API to it, or other languages?
This combined with a static html site, maybe hosted on S3, could make for a very interesting project.
How about a static HTML site hosted on Site44: http://www.site44.com? ;-)
(That's my startup's other product.)
(That's my startup's other product.)
This is awesome! May I ask whether it will support custom domains in the future?
We don't plan on supporting custom domains, because we don't think people will serve up content directly from these scripts. (We think of them more as APIs, so typically invisible to end-users.)
That said, my startup's other product (www.site44.com) is great for serving up content and does support custom domains. We plan to add support to Site44 for forwarding API calls to Webscript. So you could build a full HTML app with content served from Site44 and API calls handled by Webscript, all with a custom domain.
That said, my startup's other product (www.site44.com) is great for serving up content and does support custom domains. We plan to add support to Site44 for forwarding API calls to Webscript. So you could build a full HTML app with content served from Site44 and API calls handled by Webscript, all with a custom domain.
It is actually not about serving content. Custom domain makes the fail over much easier. For example, someone uses webscript.io as his app backend. If webscript.io goes down for whatever reason, he can simply point the URI to a backup server(provide he has one) if he uses a custom domain. Without custom domain all he can do is wait.
Ah, good point; thank you. We'll give this some more thought.
Clever ideas, on both counts (webscript and site44). I wish you and Todd success.
I signed up. Already using it to check if a server goes down. Have a lot more things I plan to use it for as well. Awesome service.
This looks like a good excuse to pick up Lua.
So, is this using embedded lua inside an actual web server like Nginx or is it a Lua application specific server ?
It's a Python app that calls into embedded Lua.
This is cool, and a very fair pricing model.
This site seems sort of ripped off from codepen.io :/
No it didn't. But with that logic codepen.io ripped off jsfiddle which ripped off jsbin which ripped off pastebin.com
In what way? I think this is a completely different project for a completely different purpose.
You mean the .io part right?
I mean the nav, the "Picks, Popular, Recent" at the top, etc. etc.
It's Bootstrap dude.
Would you mind sharing a bit about the architecture of this project? What tools and technologies & language (beside lua) did you use? I'm guessing you just need custom routes (all the URLS are on your domain?) rather than custom DNS. How are you handling sending emails, for instance? (did you plug into an email as a service provider?)
The whole thing is a Python app, written with Flask. As you said, we do custom routing to map URLs to scripts, which we then load up in a Lua VM and execute with conventions for how we pass in the request and interpret the return value.
For email, we just support SMTP. You have to bring your own server and credentials. Our examples are using Amazon SES, but anything would work (e.g. SendGrid or even GMail).
For email, we just support SMTP. You have to bring your own server and credentials. Our examples are using Amazon SES, but anything would work (e.g. SendGrid or even GMail).
Great to see another lua based service. I'm running http://geolua.com/ which also uses Python (and even gunicorn) for the web interface and lua (in a custom libevent based server) for running user provided lua code. I sandboxed lua using chroot, a custom allocator function, runtime limits using signals and an "outer" lua environment which interfaces with the python code. The inner environment should be safe. I guess :-)
How do you handle 'a = " "; while true do a = a .. a end'? Do you spawn individual processes with process limits? Which version of lua are you using? Why not luajit2?
How do you handle 'a = " "; while true do a = a .. a end'? Do you spawn individual processes with process limits? Which version of lua are you using? Why not luajit2?
Geolua looks cool. Thanks for sharing it.
It sounds like we're doing some similar things. Custom allocators are definitely the way to go to limit memory usage. We also use process-level isolation to limit the amount of execution time.
We're Lua 5.1 and not luajit2 for now for vague technical integration reasons that we may very well revisit as this takes off.
It sounds like we're doing some similar things. Custom allocators are definitely the way to go to limit memory usage. We also use process-level isolation to limit the amount of execution time.
We're Lua 5.1 and not luajit2 for now for vague technical integration reasons that we may very well revisit as this takes off.
As far as I'm aware, Python is vastly more popular for scripts than Lua. At first, I assumed you were just Lua guys, but apparently you're a Python fan as well, at least to some degree.
I imagine it must have to do with easy of sandboxing or something, but why Lua over Python for scripts?
I imagine it must have to do with easy of sandboxing or something, but why Lua over Python for scripts?
Python's my language of choice just in terms of language features, but Lua is significantly ahead in terms of embedding and sandboxing.
[deleted]
This isn't called webscript.io. It's called "webscript". It's beyond pretentious. The words "web" and "script" are extremely generic and common in software development. To put them together and not only use it as a product name but try to introduce it as a new term rubs me the wrong way. (The phrase "Webscripts are a fast and easy way to receive those webhooks" gives me the idea that they intend to do just that.)
Going past that, the video takes way too long. The best parts of the API are quite similar to request and express in node.js land. The website is vanilla Bootstrap with a few supported customizations to make it stand out more. There's little in it that shows that the team has the level of skills needed to write a platform.
Going past that, the video takes way too long. The best parts of the API are quite similar to request and express in node.js land. The website is vanilla Bootstrap with a few supported customizations to make it stand out more. There's little in it that shows that the team has the level of skills needed to write a platform.
"This isn't called webscript.io. It's called "webscript". It's beyond pretentious."
I have to say I think that's in the eye of the beholder. What's wrong with a simple name for site, even if it has a generic meaning already?
"There's little in it that shows that the team has the level of skills needed to write a platform."
What would you want to see on the site that would show this better? Why does using Bootstrap matter, or was that an unrelated observation?
I have to say I think that's in the eye of the beholder. What's wrong with a simple name for site, even if it has a generic meaning already?
"There's little in it that shows that the team has the level of skills needed to write a platform."
What would you want to see on the site that would show this better? Why does using Bootstrap matter, or was that an unrelated observation?
I agree. I don't think that it's bad to choose a simple name.
In this particular case, I feel that it's generic enough that it can be confusing/not super memorable. For those practical reasons I think this could use a better name, but I'm not going to write-off a project just because it's name is odd.
In this particular case, I feel that it's generic enough that it can be confusing/not super memorable. For those practical reasons I think this could use a better name, but I'm not going to write-off a project just because it's name is odd.
"There's little in it that shows that the team has the level of skills needed to write a platform."
Is the demo not enough? It's paradoxical having the skill of building something that is new.
Is the demo not enough? It's paradoxical having the skill of building something that is new.
Other questions, what does it mean to choose a URL? Does it host a website there which runs the script? Like a subdomain? Or am I completely thinking the wrong way here?
What can I do with your service? (like 3-5 cool examples?)
BTW I don't mean to say, "meh I won't use this cause it's not instantly clear to me", it's supposed to be constructive criticism because I think making that quick elevator pitch will get you more users! :)
And that I really prefer skimming a page of text before deciding to watch a video presentation of a service.