Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
vasilakisfil
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
61.
▲
by
vasilakisfil
8y ago
can you explain more your use case ?
62.
▲
by
vasilakisfil
8y ago
Ok, won't use Revolut again.
63.
▲
Ask HN: What happened to VoIP vision?
1 points
by
vasilakisfil
8y ago
|
0 comments
64.
▲
by
vasilakisfil
8y ago
no, I am suggesting using it based on what it provides. Lag 2-3 seconds, power: multi-cpu, up to 12 GB ram. So obviously it's not for trivial cases like "click a button, spin up a lambda" but more to "upload a video, spi
65.
▲
by
vasilakisfil
8y ago
I work 9-5, 8 hours per day including lunch (I hate companies that try to squeeze an extra hour basically telling you that they don't pay for your lunch time, yet they require 1 whole hour for your lunch, forcing you to stay 9 hours in
66.
▲
by
vasilakisfil
8y ago
on a side note, heroku can be really nice serverless provider. The instances can be created (using the API) in a couple of seconds. And you can run anything in it.
67.
▲
by
vasilakisfil
8y ago
to author: quickstart guide not working, garage11 page shows 502. I am working on something VERY similar. However, in my architecture I have a backend server that does the signaling with the remote part. So Bob uses web client to send info
68.
▲
by
vasilakisfil
8y ago
Facebook should have provided a Gmail alternative a long time ago. I am surprised how narrow minded they are in terms of long term revenue.
69.
▲
by
vasilakisfil
8y ago
That's our proposal/challenge here, come up with a model that tries to merry the best of both world (RPC and REST) but still adheres to HTTP semantics and allow clients/servers to evolve independently.
70.
▲
by
vasilakisfil
8y ago
Thanks! That was the real challenge!
71.
▲
by
vasilakisfil
8y ago
If you are talking to devices that you can't even access/control, REST is a better way of interacting with the sensors. RPC is out of the question because it tights implementation with the API. However if you talk to a client that
72.
▲
by
vasilakisfil
8y ago
Hi, author here. That was one person publication so tough to come up with tooling as well :) I think we just wanted to show that it is possible to come up with a different (better we think) architecture other than REST and that's a big
73.
▲
by
vasilakisfil
8y ago
Author here: The problem with GraphQL is that it has to re-invent everything on top of HTTP. Introspected REST reuses HTTP properties and architecture by default, making more robust and compatible with existing clients. Also related: https
74.
▲
by
vasilakisfil
8y ago
Hi, author here. AMA. But I would like to make a couple of points. For starters, a lot of people are looking for a TL;DR. There is no such thing. Same with tooling. This is an open publication and should be considered as is. The intention w
75.
▲
by
vasilakisfil
8y ago
That in combination where the company is based. If it's based in NY, they should at least pay like having someone on-site in NY. If it's based in Tynisia, they should pay at least pay like having someone on-site. If they can&#
76.
▲
by
vasilakisfil
8y ago
..or Crystal.
77.
▲
Introducing Data Transfer Project
(opensource.googleblog.com)
3 points
by
vasilakisfil
8y ago
|
0 comments
78.
▲
by
vasilakisfil
8y ago
Looks good! Unfortunately the problem with the self-hosted apps is lack of maintenance, so after a couple of years, when the author doesn't push any updates to it you will be forced to move on to an alternative. And at that point you w
79.
▲
by
vasilakisfil
8y ago
There is also Gitea: https://gitea.io
80.
▲
by
vasilakisfil
8y ago
Wow had been looking for something like that last week on github but maybe I should be using Google instead! Many thanks, you saved me a couple of months dev time!
81.
▲
by
vasilakisfil
8y ago
I am in favor of checklists for certain critical tasks, even if they are repetitive and/or boring. I think checklists are underrated.
82.
▲
by
vasilakisfil
9y ago
de-Reacting ? Are you going for plain js ? What's your use case?
83.
▲
by
vasilakisfil
9y ago
We use Ember, and it works pretty good actually. I love the addons system which allows you to speed up, but also extend an addon at anytime if it doesn't exactly fit your case. But the great thing with Ember is that anyone of us can ju
84.
▲
by
vasilakisfil
9y ago
Having worked with React and Ember, in Ember I am super productive. I can setup a whole app in a couple of days. I think the market is so big in front-end that even a relatively small market share is actually quite big in absolute numbers.
85.
▲
by
vasilakisfil
9y ago
Says an author on a site full of ads that even bypass my adblock.
86.
▲
by
vasilakisfil
9y ago
I have owned a MacBook Pro for many years (I think it was a late 2012 model as well) given by my employer in which I always run Linux in it. I was disgusted with the hardware support on Linux (especially on Wifi/Bluetooth) so I got a n
87.
▲
by
vasilakisfil
9y ago
you can just split backend from frontend and use in the frontend an all-in js framework like Ember, Angular etc or combination of different js front-end libs like react + redux + react-router.
88.
▲
by
vasilakisfil
9y ago
https://introspected.rest/ a kind-of publication and self-research around REST and APIs. One thing that I definitely learned is that these kind of things are much harder than writing some code.
89.
▲
How to choose employer
(protopapa.github.io)
2 points
by
vasilakisfil
9y ago
|
0 comments
90.
▲
MicroTypes: Composability in HTTP APIs
(youtube.com)
2 points
by
vasilakisfil
9y ago
|
0 comments
More ›