Why Synapticloop Panl?

Panl was designed to convert rather long and unfriendly (both in human readable and SEO terms) to shorter, nicer, and friendlier URL paths throughout the entire search journey.

Working with a Solr schema, the Panl configuration files translate unwieldy URL parameters into concise and precise URL paths.

In addition to the Panl Niceties detailed in the previous section, Panl was designed to

1. Have SEO friendlier URL paths with much shorter URLs than traditional query parameters
   
   This was the primary driver.
2. Abstract away the complexities of the Solr query string - being able to have a simple interface through the URL which could generate complex queries.
   
   Not having to fully understand how Solr works in the back-end abstracts away the complexity of a front-end integrator and reduces the need to have the back-end and front-end understand each-other.
3. Be quick to start up and easy to configure
   
   During development of a solution, being able to iterate over a solution, or change the way that Panl is configured is a must have.  Additionally, being able to upgrade the Panl server and have the configuration files be automatically picked up and work without any changes is a plus.
4. Protect Solr from errant queries
   
   Hiding the Solr implementation details from the end user and parsing, decoding, and validating the URL before passing the query through to Solr.  Additionally, Solr has a tendency to return an internal server error when the query string is not as it expected, and this should not disturb the return of the results.
5. Be able to present the same Solr collection in multiple different ways
   
   A single Solr collection should be able to serve up different fields and facets from the result documents without any back-end logic.
6. Have a configuration file drive the generation of the UI as much as possible
   
   Rather than hard-coding facets and then determining how to display them, being able to have a returned JSON response which can be interrogated to determine how the facets should be displayed.

What is a LPSE (pronounced 'lapse') code?

The LPSE acronym stands for Last Path Segment Encoding, deriving its name from using the last part of the URL path as a code.

In effect the (29 characters) Panl LPSE query of

/Caran+d'Ache/true/Black/bDW/

For the above Panl URL path, the LPSE code is bDW, with the query of /Caran+d'Ache/true/Black/, this gets translated to

• The brand Solr facet field is set to Caran d'Ache (using LPSE code o f b), and
• The disassemble Solr facet field is set to true (using LPSE code of D), and
• The colours Solr facet field is set to Black (using the LPSE code of W)

Contrast this with the equivalent^[6] Solr query (828 characters) of

q=*:*&facet.mincount=1&rows=10&facet.field=lead_size_indicator&facet.field=grip_material&f
acet.field=colours&facet.field=nib_shape&facet.field=diameter&facet.field=cap_shape&facet.
field=brand&facet.field=mechanism_type&facet.field=length&facet.field=hardness_indicator&f
acet.field=grip_type&facet.field=cap_material&facet.field=lead_grade_indicator&facet.field
=tubing_material&facet.field=in_built_sharpener&facet.field=disassemble&facet.field=catego
ry&facet.field=body_shape&facet.field=clip_material&facet.field=mechanism_material&facet.f
ield=lead_length&facet.field=body_material&facet.field=in_built_eraser&facet.field=grip_sh
ape&facet.field=relative_weight&facet.field=name&facet.field=nib_material&facet.field=weig
ht&facet.field=variants&facet=true&fq=brand:"Caran+d'Ache"&fq=disassemble:"true"&fq=colour
s:"Black"&q.op=AND

The effect of the two queries are identical, returning the same results, just with a much shorter URL.

As an example of a search performed on the Walmart site, the search URL of  (281 characters)

https://www.walmart.com/search?q=mechanical+pancils&min_price=4&catId=1229749_9412206&facet=subscription_eligible%3ASubscription+item%7C%7Cexclude_oos%3AShow+available+items+only%7C%7Cpencil_lead_size_pencils%3A2.0+mm+to+3.0+mm%7C%7Ccount_per_pack_facet%3A1+-+4%7C%7Ccolor%3ABlack 

If implemented with the Panl server could be the following URL of (196 characters):

https://www.walmart.com/search/mechanical-pencils/from-4$-to-15$/pencils-and-pencils-sharpeners/subscription-eligible/in-stock/lead-size-from-2.0mm-to-3.0mm/4-items-per-pack/black/qp+pdsil+lrc/

Which is shorter, far more readable, and much more SEO friendly.

The three types of LPSE codes

1. Filters - codes that filter (and generally narrow^[7]) the results - these are either the search term or a facet (Regular, Boolean, OR, DATE Range, or RANGE)
2. Parameters - codes that change the way the returned results are displayed - these are the sorting orders, number of results per page, and page numbering.  These do not filter what results are returned.
3. Operands - codes that change the way in which the filters work, for Panl the only operand available is the Solr query operand.

URL Path Nomenclature

As the design considerations were made mainly around URLs and the niceties that could be afforded to them, here is the nomenclature used throughout this book. For any URL path:

1. The the Web Server URL path, e.g.
          /products-by-brands/Caran+d'Ache/b/
2. Is then proxied through to the desired Panl CaFUP
          /mechanical-pencils/brand-fields/Caran+d'Ache/b/
3. Which will return the results from the mechanical-pencils Solr collections, only returning the fields in each document that are contained in the configuration of the brand-fields.

The Panl URL path is made up of the following parts

When references to the URL path are made throughout this book, they refer to the Collection, FieldSet, LPSE value, and LPSE code.

Is Synapticloop Panl For Me?

The tagline for Panl is "a rather pleasing companion to the Apache Solr Faceted Search Engine", and that is how it was designed and coded.  Pleasing, as it is designed to be developer implementation friendly, makes Solr nicer to work with, and the URL paths much more friendly to read (both for humans and search engines).

However, you may have a different point of view, so, before diving into it, you should evaluate whether this project is suitable for your needs. Panl is constrained by the following:

• You MUST be using a managed schema for Solr, Panl will NOT work with non-managed, or derived schemas (in fact Solr requires a managed schema for production deployments, so this will only affect the initial testing phase of your project).
• You MUST be using a Java version of at least 11.
• Panl DOES NOT include all of the options that are available to the Solr query parser, however it does cover all functionality required for a pleasant and powerful interface into the Solr search features.
• Panl WILL NOT ALLOW complex Solr query parameters (the Solr query parameter is passed through enclosed in double-quotes "), so if you need to do complex hand-crafted queries, these are not available, for example "jakarta apache"^4 "Apache Lucene", or a query that relies on using any of the characters with a special meaning (+ - && || ! ( ) { } [ ] ^ " ~ * ? : /).
• Panl IS NOT REALLY designed to be publicly accessible, instead it is designed to sit behind a proxy or service forwarder, so there is a requirement to be able to configure a proxy or service forwarder.
• Panl IS PERMISSIVE - there is no authentication, or access control lists.  If you don't want a user to be able to query the Panl server, or restrict access to a certain subset of results, then you will need to implement your own authentication, authorisation, and security layer (which comes with its own challenges).

~ ~ ~ * ~ ~ ~