in reply to Re^5: Perl microservice framework
in thread Perl microservice framework

I have already provided an example for a basis for comparison with Spring Boot, with REST as a use case, and stated a preference to avoid having to deal with disparate Perl projects that were not originally designed for microservices architecture (albeit they can be used as such).

Java has well-understood and popular ecosystems for web and microservices with clear goals for different projects (eg. the need to extend Spring with Spring Boot, and others like Quarkus and Micronaut that tailor to different developer preferences).

As some people have helpfully pointed out, Perl offers projects that can satisfy aspects of microservices:

  • Catalyst promotes convention over configuration (a style of Spring Boot)
  • Mojolicious is event-driven, can run standalone instances (a feature of Spring Boot)
  • Plack is light weight (the need for Spring Boot)
  • Myraid is unclear to me what it coordinates (my guess is BPM or deployment orchestration, or some kind of burst scaling tool)

    but this is precisely the kind of disparateness I want to avoid where there is no complete unified solution.

    A CPAN search shows projects that come close are apparently primarily only intended as management tools (as opposed to frameworks) (eg. BeeKeeper, Myraid, Narada).

    Judging on the responses received thus far, I believe that Perl has no specific microservice framework.

    • Replies are listed 'Best First'.
    Re^7: Perl microservice framework
    by Arunbear (Prior) on Dec 27, 2024 at 13:25 UTC
      It doesn't make much sense to complain about Perl projects being not originally designed for microservices, when Spring Boot was also not originally designed for microservices (though it often is used for that).

      Both Catalyst and Mojolicious can be used to implement REST style microservices. These are also the safest bets in terms of community/support. Plack is a lower level web framework, really meant for authors of web frameworks, rather than application developers.

    		[reply]
        Well does it make sense to ask a Java centered question in a Perl board?

        Instead of listing the features needed?

        It's like an US American claiming the UK has no democratic government, since there are no senators or president. (Or rather the other way round?🤔)

        PS: FWIW Russia has both, senators and president. Tsk... Unruly Britannia!

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        see Wikisyntax for the Monastery

    		[reply]
        A reply falls below the community's threshold of quality. You may see it by logging in.
        It doesn't make much sense to complain about Perl projects being not originally designed for microservices, when Spring Boot was also not originally designed for microservices (though it often is used for that).
        But it is always prudent to be cautious against using projects for which they were not designed.

        Spring Boot is a recurring top search result for recommended Java microservice frameworks. However the Perl equivalent is not obvious, therefore the question was asked.

    		[reply]
    Re^7: Perl microservice framework
    by NERDVANA (Priest) on Dec 26, 2024 at 16:12 UTC
      Java has well-understood and popular ecosystems for web and microservices with clear goals for different projects (eg. the need to extend Spring with Spring Boot, and others like Quarkus and Micronaut that tailor to different preferences).

      ...but then you'd be learning whole new frameworks any time you wanted to produce a slightly different style of web app? I'd much rather have flexible frameworks that do them all equally well.

    		[reply]
        I was looking for a workflow engine and saw Workflow advertised as "designed to fit into your system rather than force your system to fit to it". The problem with flexibility is its susceptibility to bad design and architecture when the wielder's expertise is lacking.

        Also, technology oversaturation and fads can be largely avoided by sticking to server-side, backend, core business process and logic development. Or alternatively mitigated by coercing an existing framework into solving a particular problem and then hoping the requirements don't change. Heh.

    		[reply]

    In Section Seekers of Perl Wisdom