The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2017-12-29

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 mohawk (in fact, though i didn't specify this in my comment, the reason it's still necessary is because i prefer to do TDD, so i only want to run the software being worked on via the tests, meaning being able to see the output while running in the tests is critical for that)
00:26 sri mohawk: i have no idea what you're saying here https://github.com/kraih/mojo/pull/1176#issuecomment-354376267
00:32 sri nobody cares about blib
00:33 Grinnz to rephrase: mojo is pureperl, so building it before testing serves no purpose
00:33 sri ye
00:34 sri developing mojo without a build step is a feature
00:34 preaction echo -- --lib --recurse > ~/.proverc # never worry again
00:34 sri reason we don't use Dist::Zilla
00:34 * Grinnz doesn't need a build step to test any of his dzil dists :P
00:35 Grinnz i do it anyway, because i'd rather not copy the pod tests to the repo
00:35 Grinnz but i dont have to
00:36 sri and re private env vars
00:36 sri if we were ever to make MOJO_MORBO_BACKEND public it would have to be consistent with other env vars, like MOJO_REACTOR
00:37 sri that's why there is a lot of discussion involved!
00:37 sri also tests
00:37 purl also tests are extremely hard to read
00:37 Grinnz purl: shush
00:37 purl make me!
00:38 mohawk preaction, sure! if you want to use "prove" because you don't need to see the stdout
00:38 preaction echo --verbose >> ~/.proverc
00:39 Grinnz also known as prove -lvr
00:40 mohawk every day is a school day
00:40 preaction if only i could usefully add a default list of directories to search when no other arguments are given...
00:42 mohawk_pts joined #mojo
00:42 preaction the default with --recurse is too much. it finds old builds and runs their tests too
00:42 mohawk_pts preaction, have you tried: TEST_MORBO=1 MORBO_VERBOSE=1 prove -lv t/mojo/morbo.t
00:42 preaction i don't test morbo, so no
00:44 mohawk_pts ah hang on, that's not why i'm not seeing the verbose output, hold on...
00:46 mohawk_pts if you change morbo.t to switch the "-|" to "|-" then run `prove -v` as above, it still swallows non-TAP lines
00:46 mohawk_pts the `perl` command is necessary to see those. here is the cut-down, non-blib version:
00:47 mohawk_pts TEST_MORBO=1 MORBO_VERBOSE=1 PERL5LIB=lib${PERL5LIB:+:$PERL5LIB} perl t/mojo/morbo.t
00:47 mohawk_pts using that command, plus the change above, shows the verbose output
00:48 mohawk_pts sri, Grinnz - fair point about blib being unnecessary. substitute `-Mblib` with `-Ilib`
00:54 Grinnz mohawk_pts: STDOUT has to be swallowed in order not to interfere with TAP
00:54 Grinnz there's no way around that
00:55 mohawk_pts TAP could conceivably pass through additional "noise" that it chose not to interpret
00:55 Grinnz it does, but if that noise happens to have the right series of characters, it's suddenly not going to be noise
00:55 mohawk_pts however, that would probably require dramatic software changes that wouldn't be worth it
00:56 mohawk_pts you say it does? my attempts didn't show that
00:56 Grinnz that's why the diag() and note() functions exist in Test::More
00:56 Grinnz well, TAP does
00:56 mohawk_pts fair
00:56 Grinnz i can't speak to how the various layers are implemented
00:56 mohawk_pts my reading of App::Prove is that it just calls TAP::Harness
00:57 Grinnz unfortunately, the _VERBOSE and _DEBUG env vars are usually meant to be simple one-off debugging tools and so just dump to STDOUT directly; which is not really compatible with running test files
00:57 mohawk_pts anyway, if one uses debugging warns, those aren't swallowed, so apart from a spurious "no warnings" fail, it's a workable situation
00:58 mohawk_pts i still think -Ilib on the `perl` command line in `morbo.t` would be a good idea
00:59 Grinnz it would be if your premise is true but i think you still need to prove that's an issue; i would but i haven't gotten that bored yet :P
01:00 mohawk_pts you say "one-off debugging" which is fair enough. i think that the difference in our views is because i'm keen to stay strictly within TDD, as mentioned above
01:00 mohawk_pts so if i run morbo by itself and try stuff, sure i'll see the stdout and all is good
01:00 marty joined #mojo
01:00 Grinnz right, that's what MORBO_VERBOSE was designed for
01:00 mohawk_pts but that "trying stuff" is to me less reliable and rigorous than doing that stuff through the automated test
01:01 Grinnz it would have to work differently to be compatible with test files
01:01 mohawk_pts let me try something
01:07 marty_ joined #mojo
01:08 mohawk_pts that was unexpected. with the "|-" change, i added a "diag 'YO'" to the bit that says "File changed". with prove -v, it shows up with a "# YO" as expected. adding a "# " to the stdout messages, right next to that diag, results in the "YO" showing both in prove and "perl" running, but the "File changed" only showing in "perl" running, not in "prove"
01:08 sri don't assume morbo test coverage is good
01:08 sri morbo and hypnotoad are fairly low in test coverage actually
01:08 sri because they are so hard to test
01:08 mohawk_pts given the relatively little that morbo does, its test coverage isn't bad
01:09 mohawk_pts and yes, i had assumed they were well-tested, so i'll bear that in mind
01:09 mohawk_pts sri, did you try out app-monastery?
01:09 sri ?
01:09 mohawk_pts in the tweeted replies
01:10 mohawk_pts since the whole LSP thing is what prompted my looking into morbo
01:14 mohawk_pts (the difference between diag and say above is apparently because Test::Builder uses different file handles for outputting note and diag, which is fair enough
01:15 mohawk_pts )
01:15 Grinnz correct
03:23 genio hrm. I must admit to enjoying playing with Polymer.
03:27 mohawk it seems to win all the buzzword bingo: "Web Components, Service Worker and HTTP/2"
03:28 mohawk i wonder how it interacts with React
05:04 dboehmer joined #mojo
05:42 karjala_ joined #mojo
07:14 Vandal joined #mojo
07:19 inokenty-w joined #mojo
08:13 trone joined #mojo
08:36 jamesaxl joined #mojo
09:21 dod joined #mojo
09:27 dod joined #mojo
09:29 FROGGS joined #mojo
09:45 mishanti1 So I've written a small plugin that takes a markdown-file as template and renders it as html. Now I'd also like to use layouts from Mojo to wrap around the html generated from markdown.
09:45 mishanti1 The templates are named 'foo.html.md' and the plugin is set up to handle .md. So far so good.
09:46 mishanti1 I would like to reuse the layout that is used for ordinary .ep-files, but mojo looks for a layout with a '.html.md' suffix when rendering templates with that suffix.
09:46 mishanti1 Is there a way to make mojo use the one I've already got suffixed with .html.ep?
09:47 mishanti1 So, render my 'templates/foo.html.md' but have that use 'templates/layouts/default.html.ep'.
10:14 sh14 joined #mojo
10:15 bianca joined #mojo
10:17 Vandal joined #mojo
10:58 Leffe joined #mojo
10:59 Leffe Hi.
11:00 Leffe I'm not sure how text_field from TagHelpers it's supposed to work
11:01 Leffe I put a value on the stash, and i was expecting it to appear on text_field, but this is not the case
11:02 Leffe Am I doing something wrong?
11:06 mishanti1 Leffe: Not sure what your are attempting, but it might be that you just need to add the value with param(), not add it to stash.
11:06 mishanti1 `$c->param(foo => 'bar')`
11:07 Leffe right
11:07 Leffe that will be fine.
11:08 tchaves joined #mojo
11:08 Leffe what i just want is to read data from a config file
11:08 Leffe then edit it and change it
11:08 Leffe I guess param is ok.
11:08 Leffe thanks.
11:39 hesco joined #mojo
12:42 mohawk the good news is that using OpenAPI::Client's shiny new call_p interface to call back into the same server stops the deadlock, which is great!
12:42 mohawk the bad news is that the GraphQL installation i have doesn't know what to do with a Mojo::Promise
12:43 mohawk the good news is that today i have finished making GraphQL work with promises and whatnot so shortly the above will not be a problem
13:23 bianca joined #mojo
13:50 genio mohawk: I'll never learn how it deals with React/VueJS because I've decided I can't stand either of them :)
13:55 CandyAngel What is the path (or the requirements needed) to make changes in Minion that affects backends?
14:00 pink_mist do you mean "how can I make minion use backend Y instead of X?"
14:00 pink_mist ?
14:00 CandyAngel No, I want to make it so jobs can be reparented.. but that is a backend thing (in retry_job)
14:02 CandyAngel If it needs to be like.. "in 3 major applications", I can just subclass the backend :P
14:25 kes joined #mojo
14:27 hesco joined #mojo
15:00 rmallah joined #mojo
15:07 bianca joined #mojo
15:10 Leffe joined #mojo
15:20 orev joined #mojo
15:24 gryphon joined #mojo
15:30 bianca joined #mojo
16:51 sh14 joined #mojo
17:11 pk joined #mojo
17:29 ChmEarl joined #mojo
17:30 zivester joined #mojo
18:14 elderling joined #mojo
18:29 rmallah joined #mojo
18:39 Leffe joined #mojo
18:47 disputin joined #mojo
18:50 tchaves joined #mojo
18:58 mohawk genio, my understanding of React is it's a "view" library. do you find polymer occupies that space as well?
18:59 bianca joined #mojo
19:10 genio yep, but in a much more sane way (IMO)
19:17 mohawk interesting! can i ask you to contrast them just a bit so i know what you mean by sane? :-)
19:22 Leffe joined #mojo
19:30 CandyAngel I've seen $self->stash(x => y)->render someplace and I can't remember where or why it would get used..
19:32 Grinnz considering render dumps all its args into the stash, there shouldnt be any difference to $self->render(x => y)
19:33 CandyAngel Exactly.. :|
19:33 pink_mist except it might be clearer what's intended to do the first one
19:34 Grinnz yeah i guess it could be usefully self documenting
19:36 mohawk acts as a nice example of "fluent programming" too
19:36 mohawk (a term i learned from one of jberger's advent postings)
19:56 bianca joined #mojo
20:21 bianca joined #mojo
20:26 brunoramos joined #mojo
20:43 dugword joined #mojo
20:52 wk joined #mojo
21:01 purplecoffee joined #mojo
21:08 wk Hi! During the December I have followed Mojo calender and it has been very inspiring
21:08 wk jberger++ and  batman++
21:09 wk really appreciate work you are done
21:09 wk goggled around, but did not found out:
21:10 wk is there some good way to create swagger/openapi docs from existing database schema?
21:10 mbudde joined #mojo
21:11 wk wanted to try out the combination of mojo + my database + openapi spec = REST
21:11 wk and the add graphQL into mix
21:12 wk this part was from preaction++
21:13 wk and mohawk++
21:20 mohawk wk, first of all, thanks!
21:20 wk by docs i meany
21:20 wk meant specs
21:20 mohawk i don't know of a db -> openapi generator yet
21:21 mohawk (well, when you have an openapi spec you can generate some docs from that :-)
21:21 wk yes, still needed specs first ;)
21:21 mohawk when i finish the things i intend to, you'll be able to generate a db schema from a graphql schema, as you can already in reverse
21:22 mohawk i have a question: why openapi?
21:22 geospeck joined #mojo
21:22 mohawk (i have love for openapi, but the question is worth asking :-)
21:23 wk i'd like to generate restful API to my DB, so it would be clean to have it documented same time
21:23 mohawk sure, if you're doing rest you should start from openapi :-)
21:23 mohawk just going to google...
21:24 wk so far, as i readed, it is better to have bundle rest and graphql together
21:24 wk one is better for some things, other for others
21:24 mohawk i would ask: what does rest give you?
21:25 wk it is better for searching, for example
21:25 mohawk (i googled for "database schema to openapi" - https://github.com/dzuluaga/datamodel-to-openapi looks plausible, albeit it's in JS)
21:25 mohawk better for searching how?
21:27 wk if i recall correctly, graphql handles very well getting specific dataset, when you need what to ask
21:28 mohawk uh, yes, it does?
21:28 mohawk go on
21:28 wk *need -> know
21:29 Leffe joined #mojo
21:29 wk but trying to fit ther some LIKE-type queries seemed not fit
21:29 mohawk i can't comment on what things seem like to you :-)
21:30 mohawk but implementing a findArticle(search: String!) as well as a getArticle(id: ID) is absolutely standard in gql
21:30 wk eee... i meant queryst to DB which contain LIKE operator
21:31 mohawk indeed, my GraphQL::Plugin::Convert::DBIC provides such a concept
21:31 mohawk well, adding a LIKE search eg find* would be a 5-minute job
21:31 mohawk it's absolutely idiomatic within gql and anyone who didn't implement such a thing would not be creating a good api
21:32 mohawk i think it is a mistake to judge a technology by how it is used suboptimally, don't you?
21:32 wk ok, seems i had wrong impression somehow
21:34 wk i made some testdrive on some StarWars-topic made GraphQL app, and did not figure out, how to implement LIKE queries
21:35 wk googled a bit and got impression that it is not meant to have there
21:35 mohawk it may shock you to learn that the SWAPI is not supposed to reveal every single possibility of gql
21:36 wk i am really shocked now ;)
21:36 mohawk when you understand how types work, including InputObjects, and output-type fields with arguments - you will understand that the possibilities are pretty much unlimited
21:37 mohawk if you want a query field that implements LIKE? go ahead!
21:37 mohawk all sorts of possibilities
21:37 mohawk i have yet to see an api that can't be fitted into gql
21:38 mohawk i recall recently on the graphql #general slack, someone was doing the "mind blown" thing about what people refer to as "nested mutations" - which is a limitation that a mutation can only take one set of parameters, and return one output type
21:39 trone joined #mojo
21:39 mohawk and the fantastic pattern that someone came up with, that blew this person's mind was - having nested inputobjects on the mutation. in other words, they had invented the concept of function parameters
21:39 wk when i discovered GraphQL, i tried to get picture, is there reason to abandon the idea to have rest api and read this article amongst others:
21:39 wk https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/
21:39 mohawk i have read that article
21:39 Leffe joined #mojo
21:40 wk so i thought
21:40 mohawk his point 1 is, candidly, incorrect
21:40 mohawk claiming that REST is decoupled from HTTP is an idea that would come as a surprise to most
21:41 mohawk he is also incorrect that graphql is only over http
21:41 purl okay, mohawk.
21:41 mohawk he?
21:41 purl he is rich, it will be jammed up forever or not sushi or working on cell-silicon interfacing. or incorrect that graphql is only over http
21:41 mohawk deary me
21:41 trone_ joined #mojo
21:42 mohawk someone who writes "One of the main tenants of REST is to utilize the uniform interface" - ie gets the word TENET wrong, is not someone who inspires me with their deep understanding of what they're talking about
21:43 mohawk REST with hypermedia controls is known as "web browsing". it's not really REST anymore at that point
21:45 mohawk his example of "Leveraging a cool part of HTTP" is frankly misconceived. he claims the URL thing is supplying JSON, but it's really supplying a string. only REST etc don't really have such a concept, so he's glossing that one a bit
21:45 wk if I understand you correctly, you think that GraphQL is enough for exposing APIs, if I make it clear enough to me?
21:45 wk REST is not providinganything, that GraphQL can't?
21:45 mohawk that's my thought
21:45 hesco joined #mojo
21:46 mohawk if REST *is* providing anything gql isn't, then it's not explain in mr sturgeon's article, or anywhere else that i have read
21:47 mohawk i'll stop after this point since i'm not even 25% of the way through critiquing the article, and who has that kind of time
21:48 wk there was one worry to me yet: as far i understand, in GraphQL is very easy to compile too complex queries, making easy to DDOS servers?
21:48 mohawk rather wonderfully, while he says REST is fabulous for handling eg multipart uploads thanks to mime types - with some serious hand-waving ("it's easy!") - he says gql couldn't possibly handle using exactly the same techniques, even though you obviously could use exactly the same software to do both
21:49 mohawk so, i have here for you an entire container of salt that i suggest you add to mr sturgeon's article ;-)
21:49 mohawk wk, what is it that you think is fundamental to REST that prevents DOS on it?
21:50 wk REST does not prevent hammering the service
21:51 wk you must make a lot of queries to attack server
21:51 mohawk so maybe people implement additional measures to mitigate or prevent DOS?
21:52 wk actually, that's why I talked about his, to hear out is there already some measures against it?
21:52 mohawk i'm talking about in REST land
21:52 mohawk take the same things they do, and transpose
21:55 wk you mean, how to prevent DOS in REST? if there is hammering from certain address, you can block the IP
21:56 mohawk yes
21:56 wk but if someone creates one complex query to take server down, you must have measures before executing it
21:56 mohawk yes
21:58 mohawk so if you had that concern when you were implementing your graphql service, how would you deal with that?
21:58 wk so there should be some validator before executing queries
21:59 mohawk spoiler: validation is a standard phase in gql - it's actually part of the spec
22:00 wk can't recall the right word in English, but something like ther speedlimiters for servers
22:00 mohawk adding another validation, LimitByDepthAndOrComplexity, would be incredibly idiomatic
22:00 wk so the validator my limit deepness of queries
22:00 wk *may
22:00 mohawk the validator can do anything it likes
22:00 mohawk it's code you write
22:01 mohawk i'd also consider adding some sort of "budget" to all requests passed to other services, eg a db - if it takes more than X CPU, kill it and return a failure
22:02 wk throttle was the word i was looking for ;)
22:03 mohawk sure, some sort of apikey-linked budget is a standard approach
22:03 mohawk not fundamental to REST, but an additional layer added in
22:03 mohawk just add that same layer to gql - done
22:03 mohawk work with me on this, wk :-)
22:04 wk how you mean this?
22:05 mohawk any concept that solves problems in REST can also solve the same problems in graphql
22:05 mohawk *any*
22:07 wk i am inclining to this, when i reconsidered, with most REST-apis i have seen is also pretty good possibility to generate heavy queries
22:10 Leffe joined #mojo
22:10 mohawk wk, now you're working with me :-)
22:10 wk mohawk: thank you for sharing
22:10 purl TMI TMI TMI
22:11 mohawk grin
22:11 mohawk you're very welcome
22:11 wk must work towards GraphQL a bit deeper
22:11 mohawk btw, if you'd like to join #graphql-perl, that would be great
22:11 wk this topic has had there much better place, sure
22:11 Grinnz the -perl is a bit redundant on this network isnt it :P
22:12 wk so i thought also
22:12 mohawk i highly recommend the JS gql tutorial, and offer my perl translation of it: http://blogs.perl.org/users/ed_j/2017/10/graphql-perl---graphql-js-tutorial-translation-to-graphql-perl-and-mojoliciousplugingraphql.html
22:12 wk nice!
22:12 mohawk Grinnz, that's the name of the github org, and also the repo
22:12 mohawk call it branding if you will ;-)
22:14 wk from advent calender I noticed you have still to work on GraphQL Perl-version?
22:14 wk "He is currently porting the reference GraphQL implementation from the JavaScript version to Perl."
22:15 mohawk yes i am
22:15 mohawk released 0.25 today, with async handling (finally)
22:16 wk feels so important to have it
22:16 mohawk indeed
22:17 mohawk although not quite as important as functioning executable queries :-)
22:17 mohawk functioning-but-blocking beats not-there-yet-but-will-be-fabulous-just-trust-me ;-)
22:19 purplecoffee Thank you for mojolicious and how it has been designed and written!
22:19 purplecoffee You must get this all the time, but I want to explain why I am so grateful. I have an internally-used application I wrote in 2001 which consists of apache, mysql, and a bunch of perl cgi scripts. A couple of times over the years it has been picked up and dropped onto a newer OS, but I have never had the time/opportunity to update or rewrite it. It is currently running on a pretty old version of perl - 5.8.
22:19 purplecoffee 5.
22:20 purplecoffee I use perl when I need to write some code for some purpose, but I'm not someone who could be called by any means a programmer.
22:20 purplecoffee Last month I was asked to provide api functionality for my application preferably yesterday for an urgent money-saving project.
22:21 purplecoffee Thanks to the way you designed this despite being a total newbie to this I was able to add a restful api alongside the old code and behind the old apache and it is simple and clear and it works!
22:22 purplecoffee Now I'm building a replacement server and I'm starting with the existing code and am planning to use Mojolicious::Plugin::CGI to gradually migrate the code while bringing this server live very soon.
22:23 mohawk purplecoffee, huzzah!
22:23 mohawk are you using M::P::OpenAPI?
22:23 purplecoffee No, is that something I should look into? It was done in a rush.
22:24 mohawk i highly recommend it
22:24 mohawk making an openapi spec is a thing i'd argue is worthwhile
22:24 mohawk it gives you immediate access to tools
22:24 purplecoffee Thanks and will do.
22:25 mohawk (and with a plugin it lets you add a graphql interface for free :-)
22:25 purplecoffee In the replacement server I am using the apache auth_mellon plugin for SAML with okta. So it seems to me like the simplest thing will be to keep it behind apache.
22:25 purplecoffee Am I missing something? Is there a not-too-difficult way to do saml with hypnotoad?
22:26 Grinnz something like that is probably best left to apache
22:26 purplecoffee Thanks
22:27 wk mohawk: step towards GraphQL seemed natural to me, because for REST I had to build so many special endpoints to make fewer calls. Thank you for taking time and adding balance toward GraphQL!
22:28 wk next time on #graphql-perl then!
22:28 mohawk enjoy!
23:02 Leffe joined #mojo
23:21 Leffe joined #mojo
23:34 marty joined #mojo

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary