Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Is there server-side software that we are missing in 2018?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 115 posts

Re: Ask HN: Is there server-side software that we are missing in 2018?

#61

Post by rambojazz »

simonw wrote: post #3

I'm still waiting for a rock-solid scalable open source graph database in the mold of the Freebase database engine or the amazing graph database that Facebook have built for themselves. I'm very excited about dgraph as an option here but I think it's still an area that is very open for new entrants.

This would be really useful. Now there are Fuseki and Janus[1]. Years ago there was 4store [2]. There is also gStore in development [3]. They all require a lot of help. Would be nice if somebody could pick up and help one of these.

[1] https://jena.apache.org/index.html http://janusgraph.org [2] https://github.com/4store/4store [3] https://github.com/Caesar11/gStore

Re: Ask HN: Is there server-side software that we are missing in 2018?

#62

Post by ariwilson »

gfodor wrote: post #32

I don't think anyone has solved the issues raised in Out of the Tar Pit in the data storage space. We still spend a ton of effort, perhaps more than ever before, wrangling incidental complexity. In 2018, I should be able to define a simple relational schema in 30 seconds and start using it with effectively zero constraints around data access patterns, transaction volume, and data scale, and with no design decisions n…

Doesn't this exist? Isn't it called hiring consultants / an engineering team?

Re: Ask HN: Is there server-side software that we are missing in 2018?

#63

Post by mpeter88 »

m_ke wrote: post #19

Machine learning model management and serving service. I haven't seen a decent open source framework that makes it easy to package a trained model with prepocessing and postprocessing steps and deploy it behind an API. Adding performance tracking and model validation on top of that would be great. Then there are things like queuing/batching and autoscaling. Closes thing that comes to mind right now is tensorflow serv…

The model development pipeline is still a far cry from the maturity of the software development pipeline, and will have to get there in order to reduce the hands-on heavy lifting required for model development and deployment.

Along with packaging a trained model are things like: Snapshot/versioning of the training and test data used to create the model, versioning of the model, storing versioned models in a model registry, auto-deploying models from the registry to target environments, telemetry from deployed models.

Closest I've found is https://github.com/mitdbg/modeldb, and I've spoken to the woman leading the effort. They still have data versioning as an open question, and don't see the need. But there are training set modification, results RCA, and other use cases that drive the need to catalog training/test data with the model that results.

It'll get there. Just a question of when and how.

Re: Ask HN: Is there server-side software that we are missing in 2018?

#64

Post by mhacct »

chubot wrote: post #14

I want a distributed (not cloud) file system that handles many files and WAN latency (i.e. not HDFS). It might be a cross between Git and BitTorrent. It feels like deb repos, PyPI, NPM, CPAN, CRAN, etc. should be put in there, with the addition of binaries for popular architectures. And probably Docker-like images, although I think if they are not opaque blobs, it would be better for rsync-like differential compressi…

I’m sure it misses some part of what you’re looking for but there’s an old project on github called DrFTPD that does at least part of what you’re looking for, in a relatively archaic manner. It’s designed for a distributed FTPD across WAN links. It also has mirroring / striping, user accounts, etc. I’m sure you could find some tool to help it look local if needed.

Re: Ask HN: Is there server-side software that we are missing in 2018?

#67

Post by lowry »

simonw wrote: post #6

There might be something exciting to build to help implement ludicrously fast Google-style autocomplete / typeahead Search. I've tried using MySQL, elasticsearch, PostgreSQL with trigram indices... they can be made to work, but I've never felt that I'm anywhere near the quality of whatever it is Google are doing here.

You need to go deeper and use AnalyzingSuggester from Lucene. It is as fast as it gets. Also, do not forget about the web part of the equation. Using HTTP/2 helps, as well as disabling buffering all the way through.

Re: Ask HN: Is there server-side software that we are missing in 2018?

#68

Post by mamcx »

gfodor wrote: post #32

I don't think anyone has solved the issues raised in Out of the Tar Pit in the data storage space. We still spend a ton of effort, perhaps more than ever before, wrangling incidental complexity. In 2018, I should be able to define a simple relational schema in 30 seconds and start using it with effectively zero constraints around data access patterns, transaction volume, and data scale, and with no design decisions n…

I totally agree.

I'm toying with the idea of build a relational-centric language (and maybe storage) because I think the same.

I wanna to create a table/relation as easy as:

   customers = [id:int, name:str; 1 "jhon"; 2 "doe"]
in memory. Other things as triggers, PK, FK, views, etc obscure the simplicity of the relational model and make people say weird stuff as "relational database not scale" or "are too inflexible".

I think exist a LOT of easy things to enrich the model and make it more usefull. For example, is ok to say:

   inv = [id:int, lines:Lines; 1 [id:1, qty:1, price:$10];  2 [id:1, qty:3, price:$40];]
Is totally ok to nest relations on relations (this alone could make wonders for ORM :) ).

Re: Ask HN: Is there server-side software that we are missing in 2018?

#69

Post by mamcx »

gfodor wrote: post #32

I don't think anyone has solved the issues raised in Out of the Tar Pit in the data storage space. We still spend a ton of effort, perhaps more than ever before, wrangling incidental complexity. In 2018, I should be able to define a simple relational schema in 30 seconds and start using it with effectively zero constraints around data access patterns, transaction volume, and data scale, and with no design decisions n…

> I should be able to define a simple relational schema in 30 seconds and start using it with effectively zero constraints around data access patterns, transaction volume, and data scale, and with no design decisions needing to be made around these bits of incidental complexity

Oh, this also is something that need a better way!

RDBMS are too coupled. I remember to ask if I can ditch the SQL parsing of sqlite and call directly the storage (so I can put my own query engine on top) and that was like if I'm nuts!.

I think is possible to build a RDBMS that is semi-plugable. To make things as swap parts of the engine on "user land". If someone for example wanna create a new kind of index is must be as easy as write:

   fun CoolIndex.get(key) -> Value
and plug it into the engine just fine. I think do something like flask/django-esque framework where is possible to have custom fields, validations, middlewares, etc on top of a core storage layer and a default implementation.

So, instead of go with redis or something else I could build my "redis-like" api INSIDE the engine and get the advantages of locality, integrity, etc.

ie: See a RDBMS as an API Backend.

This could be model (instead of MVC in common web frameworks) as CQRS or something similar.

Post reply on HN