| Time |
S |
Nick |
Message |
| 00:00 |
|
|
fuzzyhorns joined #rest |
| 00:08 |
|
whartung |
2xx on success, and whatever the appropriate 4xx or 5xx error |
| 00:24 |
|
fred-fri |
arguably successful puts should return 200 with the whole updated thing |
| 00:24 |
|
whartung |
sure, it can do that |
| 00:25 |
|
fred-fri |
lol the update methods in our codebase return... wait for it... the amount of updated rows (i.e. 0 for failed update, 1 for successful update) |
| 00:26 |
|
fred-fri |
doesnt feel super meaningful =) |
| 00:27 |
|
whartung |
:) |
| 00:57 |
|
|
Coldblackice joined #rest |
| 01:30 |
|
|
alxbl joined #rest |
| 01:30 |
|
|
alxbl_ joined #rest |
| 01:36 |
|
sfisque |
fred-fri successful puts should return any 2xx code, depending on context (as whartung pointed out). some of ours return 203 because the process is assynchronous |
| 01:39 |
|
fred-fri |
whartung sfisque cheers for your feedbck |
| 01:49 |
|
sfisque |
searchbot google http return codes 2xx |
| 01:49 |
|
searchbot |
sfisque: List of HTTP status codes - Wikipedia, the free encyclopedia: <https://en.wikipedia.org/wiki/List_of_HTTP_status_codes>; HTTP/1.1: Status Code Definitions: <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>; HTTP Status Codes - 2xx - WebSitePulse: <http://www.websitepulse.com/kb/2xx_http_status_codes.html>; HTTP Status Codes - AskApache: <http://www.askapache.com/net/http-status- (2 more messages) |
| 03:12 |
|
|
fuzzyhorns joined #rest |
| 03:19 |
|
|
64MAC6DSJ joined #rest |
| 04:12 |
|
|
Coldblackice joined #rest |
| 04:38 |
|
|
Darkman802 joined #rest |
| 05:46 |
|
|
alxbl joined #rest |
| 06:26 |
|
|
_ollie joined #rest |
| 06:34 |
|
|
Coldblackice joined #rest |
| 07:37 |
|
|
interop_madness joined #rest |
| 07:46 |
|
|
Left_Turn joined #rest |
| 08:17 |
|
|
graste joined #rest |
| 08:41 |
|
|
quimrstorres joined #rest |
| 08:48 |
|
|
quimrstorres joined #rest |
| 11:17 |
|
|
fuzzyhorns joined #rest |
| 11:18 |
|
|
fuzzyhorns joined #rest |
| 12:25 |
|
|
quimrstorres joined #rest |
| 12:58 |
|
|
rosstuck joined #rest |
| 14:17 |
|
|
graste joined #rest |
| 14:18 |
|
|
foist joined #rest |
| 14:42 |
|
|
graste joined #rest |
| 14:44 |
|
|
rosstuck joined #rest |
| 15:13 |
|
|
graste joined #rest |
| 15:43 |
|
|
sfisque joined #rest |
| 15:47 |
|
|
baweaver joined #rest |
| 15:53 |
|
|
ralphschindler joined #rest |
| 16:55 |
|
|
andreas_ joined #rest |
| 16:57 |
|
andreas_ |
I absolutley don't want to start a flamewar of languages to build a REST api in. So just lets say Pre-compiled and Runtime-Compiled languages. I have not seen any numbers of performance for the two difference. But I do understand there is. But is the difference that big that added some CPU power to a server cant compensate it, or will it escalate quickly with high load? |
| 16:58 |
|
whartung |
I won't say it doesn't matter -- but…it probably doesn't matter. Most load is tied to persistence, not processing (for generic applications). |
| 16:59 |
|
whartung |
That said, there are lots of stories of company starting on X platform and moving to Y platform for efficiencies, etc. |
| 16:59 |
|
whartung |
but it becomes a question of how much $$$ the infrastrcuture is consuming compared to the developers. |
| 16:59 |
|
whartung |
When you're Twitter or Facebook, it matters, but they have other scaling issues to deal with as well. |
| 16:59 |
|
whartung |
most folks aren't twitter or facebook tho |
| 17:00 |
|
asdf` |
eh, the thing is, we're usually talking about APIs in the context of web or the internet, so the RTT alone is usually >50ms; so the difference between 100ms request for a slow python program vs 10ms request for a fast C++ program gets somewhat diluted; and as for throughput, these kinds of things tend to scale well by adding more machines |
| 17:00 |
|
whartung |
Lots of stuff gets written, producitively, and efficiently in Ruby all day long all over the world, and ruby is basically one of the worst when it comes to raw performance. |
| 17:01 |
|
whartung |
yea, performance is a hardware scaling issue, not a user repsonse time issue |
| 17:01 |
|
andreas_ |
Lots of intresting thoughts. |
| 17:04 |
|
andreas_ |
today we are a kind of new startup with a hope to become really big, maybe not Twitter/Facebook big. But according the the user base we have now and only been live a few weeks it might be some really high numbers. Last 4 weeks we have had 120 new costumers, all have perosnlly been invited. No public signup form. And have a daily usage of arround 600 - 1200 site views. |
| 17:04 |
|
whartung |
don't we all want to be big. |
| 17:04 |
|
whartung |
:) |
| 17:04 |
|
andreas_ |
Yeah exactly ;) |
| 17:05 |
|
whartung |
but see, if your system can "scale", then you can "throw hardware at the problem" |
| 17:05 |
|
whartung |
as you rload increases |
| 17:05 |
|
whartung |
your bottlenecks will always be persistence |
| 17:05 |
|
whartung |
that's just raw truth |
| 17:05 |
|
asdf` |
but becoming big is a question of throughput, and that's mostly an infrastructure issue - choice of the rdbms, choice of your message queues etc |
| 17:05 |
|
whartung |
any system out there can handle a zillion tps of we traffic. |
| 17:05 |
|
asdf` |
programming language tends to influence latency more, and latency isn't that important most of the time |
| 17:05 |
|
whartung |
some more zillion than others, but it's rarely the limiter |
| 17:06 |
|
andreas_ |
Ok, so to rewrite everything is probably just a waste of time? (This is done primarly without any salary) so it wont cost the company anything except time ;) |
| 17:07 |
|
asdf` |
are you facing some performance issues already? |
| 17:07 |
|
whartung |
when you get big, you can hire people to rewrite it. You'll want to go 2.0 by then anyway :) |
| 17:09 |
|
andreas_ |
asdf`: No, but I want to avoid it so I might rather spend some time to rewrite something then to get the problem and then have to do it really fast because we have problems |
| 17:09 |
|
andreas_ |
whartung: That is a valid point! :) |
| 17:09 |
|
whartung |
simply put, if you have time to rewrite it now, you're not busy enough. |
| 17:09 |
|
asdf` |
andreas_, what's your stack, btw? as in, programming language etc? |
| 17:10 |
|
whartung |
most folks at this stage of development are piling on features, so dev bandwidth is going to that, not rewriting working code. |
| 17:11 |
|
andreas_ |
whartung: Time is what we make it in my oppinion. Sure there is 10000 new features we need to add. But we also see that if we go to far, and then realising we have to rewrite the cost will be much bigger as well as the time that it takes. |
| 17:12 |
|
andreas_ |
asdf`: PHP using Laravel 4.2 framework. Thought of going to 5.1 and that got me starting thinking about this. |
| 17:12 |
|
asdf` |
oh, php, alright |
| 17:12 |
|
andreas_ |
Because I wanted to add Angular JS for the frontend so need to build an API like approach instead the.n |
| 17:13 |
|
andreas_ |
And if doing that I either have to modify my current code to make it an RestAPI/api and then use angular. Or I might change to Go/C# and start to make it an api directloy. |
| 17:13 |
|
whartung |
if you're not persisting, you can scale. If you not persisting in real time (i.e. eventially consistent), you can scale. If you are, you need to work on those problems. |
| 17:14 |
|
whartung |
there's nothing wrong with PHP in this context (all sorts of things wrong with PHP, but this isn't one of them). There's always advantages in this industy to "the devil you know". No project has failed due to platform choice, it's always something else that crushed it. |
| 17:16 |
|
andreas_ |
I'm sorry but engligh is not my first language. Could you please explain persistance what it mean in this context? I might know what you mean but not understanding it. :) |
| 17:16 |
|
whartung |
saving data to disk |
| 17:16 |
|
whartung |
to permanent storage |
| 17:16 |
|
andreas_ |
Ah, so like an SQL-database ? |
| 17:16 |
|
andreas_ |
for the data. |
| 17:16 |
|
whartung |
yes |
| 17:17 |
|
whartung |
saving data to disk is fast. Saving data to disk in a way that makes it easy to get individual pieces back out quickly, is not. |
| 17:18 |
|
andreas_ |
So a MySQL database is not good in that way then. :) |
| 17:18 |
|
whartung |
not saying that either. "It depends" |
| 17:18 |
|
whartung |
or let me put it this way. |
| 17:19 |
|
whartung |
No MySQL database is not good that way. That said, nothing is good that way. That's why it's a problem. |
| 17:19 |
|
whartung |
That's why we have mysql, postgres, mongo, redis, kafka, Oracle RAC, blah de blah de blah. |
| 17:20 |
|
whartung |
they all try to solve pieces of the problem. |
| 17:20 |
|
whartung |
But it's a hard problem. |
| 17:21 |
|
andreas_ |
Ok |
| 17:21 |
|
whartung |
the nice thing today is that the cloud providers like amazon let you cheaply try out architectures that you hope can handle large volumes, and generate those volumes. |
| 17:22 |
|
andreas_ |
generate those volumes? THey can testrun my site with high volumes? |
| 17:22 |
|
whartung |
if you're expecting to "go big" you need to understand what "big" means, simulate the traffic, decide what you want to do with it, and plan your responses |
| 17:23 |
|
whartung |
it's easy to spool up a dozen machine running load testers to simulate a bunch of clients, something that's hard to do in your office unless you have a rack of machine sitting around warming the server room |
| 17:23 |
|
andreas_ |
:) |
| 17:23 |
|
andreas_ |
No serverroom at all today. But could I use this amazon feature on my curent VPS? |
| 17:24 |
|
andreas_ |
To test my site under big load? |
| 17:24 |
|
whartung |
it's nothing special about amazon, just the idea that you have a lot of machines at your fingertips (from most any cloud provider that bills my the minute) for cheap. |
| 17:25 |
|
andreas_ |
Ah you mean in that sence. I get it. |
| 17:25 |
|
whartung |
$10 of CPU time can genrate a huge amout of taffic |
| 17:25 |
|
andreas_ |
I thought this was some service they had. |
| 17:25 |
|
whartung |
no |
| 17:25 |
|
andreas_ |
When googling it I found loadimpact.com though :) |
| 17:25 |
|
andreas_ |
And they do it :) |
| 17:25 |
|
whartung |
no doubt someone does this |
| 17:26 |
|
andreas_ |
:) |
| 17:33 |
|
andreas_ |
Maybe my eager to use C#/Go is bigger then the need for my project, it sure sounds like it when getting your inputs. |
| 17:37 |
|
whartung |
probably |
| 17:45 |
|
andreas_ |
Seams like a better whin will be to change to HHVM or wait out PHP7 then to go with Precompiled language. When you take into account the time it takes to rewrite :) |
| 17:50 |
|
whartung |
probablu |
| 17:53 |
|
andreas_ |
Word of the day. Probably :) |
| 18:37 |
|
|
sfisque joined #rest |
| 20:01 |
|
|
ralphschindler joined #rest |
| 20:50 |
|
|
FreezingDroid joined #rest |
| 21:17 |
|
|
Coldblackice joined #rest |
| 21:43 |
|
|
ralphschindler joined #rest |
| 22:10 |
|
|
travelr joined #rest |
| 22:11 |
|
travelr |
Is it just my observation or the REST hype has died down in the last year or so |
| 22:13 |
|
whartung |
It's got overcome by REST == JSON RPC over HTTP |
| 22:16 |
|
travelr |
Aww |
| 22:16 |
|
travelr |
I'm trying to hit the middle ground. |
| 22:16 |
|
travelr |
I respect the semantics of HTTP methods... |
| 22:16 |
|
travelr |
But I have my own methods on top of them. |
| 22:17 |
|
travelr |
Because my awesomeness can't be contained in the ones HTTP has. |
| 22:18 |
|
whartung |
it's good to be awesome |
| 22:18 |
|
asdf` |
travelr, this might mean you didn't design your program in terms of resources; and might lead to not having a uniform interface, so writing clients won't be as easy |
| 22:19 |
|
whartung |
not necessarily, you can have a uniform interface with verbs beside PUT, POST, GET and DELETE |
| 22:20 |
|
asdf` |
if they are indeed uniform across resources, as opposed to each resource exposing some of its own methods |
| 22:20 |
|
whartung |
si |
| 23:28 |
|
|
fuzzyhor_ joined #rest |
