pelias
feat(debug): add parser demo frontend to api
This change hosts the parser /demo web frontend on the api server.
The reason for this is that the parser version at https://parser.demo.geocode.earth/ can be quite different from what's running in prod on a pelias api box, so it's useful to be able to play with the exact version of the parser that's running.
I don't want a million serveXFrontend options in the code, so I'm wondering if it makes sense to deprecate serveCompareFrontend and instead change it to something like serveDebugFrontends that would encompass a range of tools?
If people like this, in a later change I can play with linking from /frontend to this, as well as adding them to the index page (if they are enabled in prod) until the team builds a better landing experience
yay, glad this works for you
On Fri, Jun 5, 2020 at 5:15 PM Jones Magloire [email protected] wrote:
@Joxit approved this pull request.
IDK if I will use this feature one day, but I like the configuration exposeInternalDebugTools
One ring to rule them all ! 💍
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pelias/api/pull/1434#pullrequestreview-425629575, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADMZMGUTM2C346JGSHVVEDRVFN6VANCNFSM4NFC6Q6Q .
-- David Blackman creative technologist & wandering help me find my purpose http://purpose.blackmad.com
moving the parser route would be a pain because in parser, the demo is served at /demo/ and queries parser at /parser/parse, so it can't just be a relative url since we want to mount it at /frontend
I don't think it's a great use of time to make the parser demo much more configurable. There's a gross hack where we dynamically do a search-and-replace on the parser demo FE index.html as we serve it but that's pretty gross. If you're not comfortable with this change I can just close it.
Heya,
As discussed on our call, I am fine with adding a bunch of debugging tools but we'd like to keep them under a common path prefix (ie. all under /frontend/*).
This will allow us to continue adding more debugging functionality in the future without having to worry about the public REST API changing.
The parser demo makes this difficult because of this one line specifically 😡
There seem to be a two solutions, neither of which is what I would call ideal, but they are both workable to get this merged:
- instead of using
express.static()you can read that HTML file, do a string replacement on/parser/parseand serve it from the modified string. - we could clean that up a bit by introducing a variable in the HTML (to make the string replacement less error-prone), or a fully fledged templating system, although that seems to be overkill (maybe not!?)
if this is good to merge, then someone from pelias team can do it, otherwise I'll close the PR