agconti

Joined 12 years ago

Karma
115
Submissions
34
Member since
Mar 27
[ my public key: https://keybase.io/agconti; my proof: https://keybase.io/agconti/sigs/TyRj8PUE0Xw17y20q-05hnd_wL8IjUd7staIsOiX_o8 ]

@agconti

https://github.com/agconti

View on Hacker News

Recent submissions

Comment · 5 years ago
Hey HN!

Andrew here (https://www.linkedin.com/in/agconti/). I'm the founder of Reactive Streaming, (https://www.reactive-streaming.com), a platform as a service that enables product and growth teams to create interactive live experiences through our easy to use APIs. We make it easy for you to build a live experience by taking care of the foundational live streaming technical challenges so you can focus on what differentiates your product.

- we have the fastest live video in the market, thanks to our propriety live streaming process.

- our interaction services, (a BAAS), lets you create deeply engaging visceral experiences with ease.

Want the skinny on what we offer? Here is a video: https://www.reactive-streaming.com/product-demo/

I'm located in NYC and I'm looking for a co-founder with deep sales and marketing experience. If you're interested, please reach out to me on LinkedIn!

Comment · 5 years ago
Comment · 8 years ago
Django fits this bill.
Comment · 8 years ago
That’s cool and I hear you; that’s a complex relevancy definition.

( Maybe surprisingly? ) This is type of query is natively supported by Postgres. That support is robust and mature, you don’t have to hack it together.

ES is a great tool and it’s clear your a fan of it. If you’re interested, I’d recommend you look into Postgres capabilities. It’s not a replacement for ES by any means ( or even a competitor to in my opinion; Postgres isn’t even distributed ). But for specific use cases, you might find that Postgres capabilities surprise you!

Comment · 8 years ago
The Postgres docs suggest using another column. My guess is that an expression index would be too large if it held the tokenized value of all of your FTS documents. These things can and often are entire written documents. Imagine the index size for 2 Million rows of tokenized documents at 2,000 words each.

You might be able to get away with if if you were indexing a less then large amount of very small documents.

I like your expression index idea a lot.

Comment · 8 years ago
I'd argue that relevancy is more your application application's design then the underlying system retrieving the results. For example, putting the same dataset in Postgres or ES wouldn't make one deliver more relevant results given equal configurations.

You could lean on the relevancy strategies built in to ES, but in my experience you're better off understanding what relevancy means for your dataset and implementing a strategy yourself. Your millage may vary though, I'd never advocate reimplenting something that's already provided by your chosen tool.

The options and tools for configuring and tweaking relevancy between ES and PostgreSQL's FTS are surprisingly similar for many application use cases. If you're interested you can check out Postgres' search rank and query weighting configurations.

Comment · 8 years ago
Absolutely.

- Using a `SearchVectorField` is a must after 500K rows.

- Make keeping this field up to date easy for yourself by populating it using `SeachVector` with a Django pre_save signal or PostgreSQL trigger. This reduces CPU utilization significantly as the parsing and tokenization of the field your searching on is done a head of time.

- Adding a GIN Index on your `SearchVectorField` column will improve performance dramatically.

- You should specify your language configuration for postgres FTS parser. The default parser doesn't do much. It just removes spaces and normalize case. Specifying a language lets the parser make heavier optimizations that noticeably improve performance and the quality of results. If you need support for more then one langue, Django already makes it easy for this configuration to be dynamic.

Comment · 8 years ago
I can deeply vouch for the performance and joy of implementing Full-Text Search with PostgreSQL and Django.

I just finished a a project where we chose Postgres's FTS over using Elastic Search. At the beginning, I was worried about what performance we'd see since we choose to not use ES. But after slight performance tweaking, we had even our least performing queries under 50ms.

Comment · 8 years ago
Comment · 8 years ago
Hey sheraz — thanks for the feedback!

Your recommendations look great, especially libclould.

What do you think can be beefed up in getting started docs? Getting setup on your laptop should be as simple as cookiecutting your app and running `docker-compose up`. Is there something missing that you’d like to see documentation about?

I agree with feedback about Heroku. Professionally, I use Kubernetes and I’m looking forward to when amazon’s managed kubernetes service is out of developer preview so this project can use it. I’ve kept with Heroku because its such a nice platform to get an app started on. It allows you to rapidly develop your app from 0 to 1 without being over encumbered by infrastructure concerns before you need to be. I’ve also kept it in because the integration is just pushing to a docker repository. Just changing the repository destination gives you continuous deployment to anywhere. I like that its flexible and doesn't lock you into a vendor.

Would you rather have continuous deployment to Heroku removed then included?

Comment · 8 years ago
Hey ya’ll,

I’m the creator of cookiecutter-django-rest. I’m super happy to share this release with you. This is a big one.

What api frameworks do you use?

What kind of enhancements are you looking for?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton