8 ms·

For developers, we have an API (http://swiftype.com/documentation/quickstart http://swiftype.com/documentation/quickstart) that is not much different than setti

by 100k 14y ago

For developers, we have an API (http://swiftype.com/documentation/quickstart http://swiftype.com/documentation/quickstart) that is not much different than setting up Solr or ElasticSearch. However, you no longer need to manage the search servers. We handle reliablity and scaling. On top of that, we offer client libraries (like SwiftypeTouch), search analytics, and a management dashboard (think: you write the search, the business people take over managing the results). For less technical users, we have a web crawler with automates the creation of search engines. Combined with our crawler controls and meta tags (http://swiftype.com/documentation/meta_tags http://swiftype.com/documentation/meta_tags) you can build a really powerful site search engine with little effort.

hnriot 14y ago
thanks for the information. Speaking as someone who has worked in the search industry for many years I am surprised to see this. For me, setting up an ES server on AWS and pushing content directly into it seems pretty trivial, but I get the business analytics, dashboard etc. The meta tags seems like a reinvention of og?
- 100k 14y ago
  How about scaling that ES server to 100,000+ queries a day? ;-) We support a few og tags as well, but our goal is ultimately to be able to make very flexible search engines without code, so the person managing (say) the help section of a website can make an amazing search engine without involving engineering.
  - hnriot 14y ago
    100k per day is just over 1 q/s, which shouldn't concern any scale engineer. If you take that two or three orders of magnitude higher it starts to become something the scale engineer pays attention to, otherwise, I don't see the concern with that low qps. I get that it's cloud based, with all the elastic benefits that affords, but if I look at this from a VC perspective we have two use cases: - the customers with their own private data that wouldn't trust two guys in a "garage" in Potrero Hill. - the customers that want a no engineering solution to providing a no-engineering solution to making a section of their website searchable. This seems pretty much covered by Google's search offerings in this area. Complete with a scale out story beyond the wildest dreams of a startup. It also has the huge benefit of a relevance engine that is best in class. Clearly, if you have customers, I am wrong!
- prateekdayal 14y ago
  We have been using Swiftype at SupportBee for searching the help docs - https://supportbee.com/helps https://supportbee.com/helps. We still use ES for core application search (tickets etc) but for things like help documentation, site search etc it's hard to beat Swiftype's setup time and ease of use. The analytics is pretty useful too. Disclaimer: Swiftype is our customer as well but we used them for many months before they found out about us and signed up :)
  - bosky101 14y ago
    404, guess that was https://supportbee.com/help https://supportbee.com/help funny though that it shows 0 results for "supportbee"

by 100k 14y ago

hnriot 14y ago

thanks for the information. Speaking as someone who has worked in the search industry for many years I am surprised to see this. For me, setting up an ES server on AWS and pushing content directly into it seems pretty trivial, but I get the business analytics, dashboard etc. The meta tags seems like a reinvention of og?

100k 14y ago
How about scaling that ES server to 100,000+ queries a day? ;-) We support a few og tags as well, but our goal is ultimately to be able to make very flexible search engines without code, so the person managing (say) the help section of a website can make an amazing search engine without involving engineering.
- hnriot 14y ago
  100k per day is just over 1 q/s, which shouldn't concern any scale engineer. If you take that two or three orders of magnitude higher it starts to become something the scale engineer pays attention to, otherwise, I don't see the concern with that low qps. I get that it's cloud based, with all the elastic benefits that affords, but if I look at this from a VC perspective we have two use cases: - the customers with their own private data that wouldn't trust two guys in a "garage" in Potrero Hill. - the customers that want a no engineering solution to providing a no-engineering solution to making a section of their website searchable. This seems pretty much covered by Google's search offerings in this area. Complete with a scale out story beyond the wildest dreams of a startup. It also has the huge benefit of a relevance engine that is best in class. Clearly, if you have customers, I am wrong!
prateekdayal 14y ago
We have been using Swiftype at SupportBee for searching the help docs - https://supportbee.com/helps https://supportbee.com/helps. We still use ES for core application search (tickets etc) but for things like help documentation, site search etc it's hard to beat Swiftype's setup time and ease of use. The analytics is pretty useful too. Disclaimer: Swiftype is our customer as well but we used them for many months before they found out about us and signed up :)
- bosky101 14y ago
  404, guess that was https://supportbee.com/help https://supportbee.com/help funny though that it shows 0 results for "supportbee"