You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Paden <ru...@gmail.com> on 2015/06/23 23:20:56 UTC
Creating A User Interface On Top of Solr
Hello,
I'm trying to custom build my own Solr interface in Visual Studios instead
of using/modifying the original Velocity interface. I'm mostly doing this as
a learning exercise for building UI that's why I'm opting out of using it.
The problem is I'm pretty new and not sure where to begin. Most of the posts
I've seen end in people opting to modify the default UI. Are there any good
links to tutorials or good Solr classes I should look at as I'm trying to
build this UI?
This interface isn't to replace the Solr Admin page, it's simply to handle
the querying of the indexed documents that I have.
If this seems more an "exercise in futility" (due to vast amounts of code
that needs written or whatnot) then please let me know. I don't really have
any reason to believe it should be but I've been wrong before.
Thanks in advance
--
View this message in context: http://lucene.472066.n3.nabble.com/Creating-A-User-Interface-On-Top-of-Solr-tp4213541.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Creating A User Interface On Top of Solr
Posted by Shawn Heisey <ap...@elyograg.org>.
On 6/24/2015 4:16 AM, Alessandro Benedetti wrote:
> related that I noticed that a lot of times, a developer would need an
> intermediate API that will proxy the Search UI requests to Solr.
>
> Of course there are scenarios where is necessary to build this intermediate
> API ( for example if you customise how the results must be processed after
> Solr returns them) .
> But sometimes it can happen a straightforward communication from the UI to
> Solr using the REST endpoints provided .
>
> In your opinion, does make any sense to provide the intermediate Search API
> in simple use cases as well ?
> Doing that, aren't we introducing scalability issues/ delay in query time ?
>
> I always thought the intermediate Rest API to be necessary, but day by day,
> Solr REST API are becoming more and more complete.
>
> To refer to the the user mail, maybe he can simply use Solr REST endpoints.
> But what about production environments ?
Solr's REST-like interface is indeed becoming more and more complete ...
which is part of the problem. It's a bad idea to expose Solr directly
to end users, because as Erick said, users with direct access to Solr
can wipe out your index, change it in subtle ways, and access things you
may not have wanted them to access. When we add another feature to Solr
that allows administrators to modify the Solr config or index, it makes
end-user access that much more dangerous.
Even if you implement a proxy for Solr that blocks access to the admin
UI and the update handler, a user can still craft queries with enough
complexity to keep the Solr server busy and cause denial of service.
Configuring a proxy for that role requires time, which might be better
spent on an intermediate UI.
Chances are that if you're building a website, you're going to invest
heavily in writing a user interface, part of which will run on the
server side. It might be in a language like PHP, Ruby, or Java. Adding
Solr support to such an interface is normally pretty easy, because Solr
clients are available for several languages that are commonly used for
website design.
https://wiki.apache.org/solr/IntegratingSolr
A modern interface will include plenty of Javascript, which runs in the
user's browser, but I expect that the sensitive parts will run
server-side. As an example, there are Solr plugins available for
applications like Wordpress and Drupal. Those plugins are server-side
code, and do not require end-user access to Solr.
Thanks,
Shawn
Re: Creating A User Interface On Top of Solr
Posted by Alessandro Benedetti <be...@gmail.com>.
Erick,
related that I noticed that a lot of times, a developer would need an
intermediate API that will proxy the Search UI requests to Solr.
Of course there are scenarios where is necessary to build this intermediate
API ( for example if you customise how the results must be processed after
Solr returns them) .
But sometimes it can happen a straightforward communication from the UI to
Solr using the REST endpoints provided .
In your opinion, does make any sense to provide the intermediate Search API
in simple use cases as well ?
Doing that, aren't we introducing scalability issues/ delay in query time ?
I always thought the intermediate Rest API to be necessary, but day by day,
Solr REST API are becoming more and more complete.
To refer to the the user mail, maybe he can simply use Solr REST endpoints.
But what about production environments ?
Cheers
2015-06-24 2:18 GMT+01:00 Erick Erickson <er...@gmail.com>:
> First, the Velocity UI was never intended to be a user-facing application,
> if
> for no other reason than it has direct access to Solr. And I can delete
> all the
> docs in the collection, delete collections, create new collections and
> all manner
> of other really bad stuff.
>
> So almost _every_ application has its own UI for search.
>
> You don't need to worry in the least about the Solr code base. You
> shouldn't
> have to care. All you need to do is send HTTP requests to Solr and deal
> with
> the response.
>
> For instance, try these two commands from a browser:
> http://sever:port/solr/collection/query?q=*:*
> (that's star colon star in case your e-mail makes the colon just a bold).
> http://sever:port/solr/collection/select?q=*:*
>
> You should see a JSON and XML response packet. _That's_ all you
> really have to deal with. The rest of theUI has nothing to do with
> Solr and everything to do with your UI skills, you "merely" have to parse
> the response and display it pleasingly.
>
> If you don't want to curl the commands or use your own HTTP client, you
> can use SolrJ to query Solr and not have to parse the response because
> there are a bunch of helper methods that make navigating the response
> easier, google "solrj query example" and you'll see a bunch of examples. Be
> a little careful to make sure the example you use is compatible with your
> Solr version.
>
> HTH,
> Erick
>
> On Tue, Jun 23, 2015 at 5:20 PM, Paden <ru...@gmail.com> wrote:
> > Hello,
> >
> > I'm trying to custom build my own Solr interface in Visual Studios
> instead
> > of using/modifying the original Velocity interface. I'm mostly doing
> this as
> > a learning exercise for building UI that's why I'm opting out of using
> it.
> >
> > The problem is I'm pretty new and not sure where to begin. Most of the
> posts
> > I've seen end in people opting to modify the default UI. Are there any
> good
> > links to tutorials or good Solr classes I should look at as I'm trying to
> > build this UI?
> >
> > This interface isn't to replace the Solr Admin page, it's simply to
> handle
> > the querying of the indexed documents that I have.
> >
> > If this seems more an "exercise in futility" (due to vast amounts of code
> > that needs written or whatnot) then please let me know. I don't really
> have
> > any reason to believe it should be but I've been wrong before.
> >
> > Thanks in advance
> >
> >
> >
> > --
> > View this message in context:
> http://lucene.472066.n3.nabble.com/Creating-A-User-Interface-On-Top-of-Solr-tp4213541.html
> > Sent from the Solr - User mailing list archive at Nabble.com.
>
--
--------------------------
Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti
"Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?"
William Blake - Songs of Experience -1794 England
Re: Creating A User Interface On Top of Solr
Posted by Erick Erickson <er...@gmail.com>.
First, the Velocity UI was never intended to be a user-facing application, if
for no other reason than it has direct access to Solr. And I can delete all the
docs in the collection, delete collections, create new collections and
all manner
of other really bad stuff.
So almost _every_ application has its own UI for search.
You don't need to worry in the least about the Solr code base. You shouldn't
have to care. All you need to do is send HTTP requests to Solr and deal with
the response.
For instance, try these two commands from a browser:
http://sever:port/solr/collection/query?q=*:*
(that's star colon star in case your e-mail makes the colon just a bold).
http://sever:port/solr/collection/select?q=*:*
You should see a JSON and XML response packet. _That's_ all you
really have to deal with. The rest of theUI has nothing to do with
Solr and everything to do with your UI skills, you "merely" have to parse
the response and display it pleasingly.
If you don't want to curl the commands or use your own HTTP client, you
can use SolrJ to query Solr and not have to parse the response because
there are a bunch of helper methods that make navigating the response
easier, google "solrj query example" and you'll see a bunch of examples. Be
a little careful to make sure the example you use is compatible with your
Solr version.
HTH,
Erick
On Tue, Jun 23, 2015 at 5:20 PM, Paden <ru...@gmail.com> wrote:
> Hello,
>
> I'm trying to custom build my own Solr interface in Visual Studios instead
> of using/modifying the original Velocity interface. I'm mostly doing this as
> a learning exercise for building UI that's why I'm opting out of using it.
>
> The problem is I'm pretty new and not sure where to begin. Most of the posts
> I've seen end in people opting to modify the default UI. Are there any good
> links to tutorials or good Solr classes I should look at as I'm trying to
> build this UI?
>
> This interface isn't to replace the Solr Admin page, it's simply to handle
> the querying of the indexed documents that I have.
>
> If this seems more an "exercise in futility" (due to vast amounts of code
> that needs written or whatnot) then please let me know. I don't really have
> any reason to believe it should be but I've been wrong before.
>
> Thanks in advance
>
>
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Creating-A-User-Interface-On-Top-of-Solr-tp4213541.html
> Sent from the Solr - User mailing list archive at Nabble.com.