Home Explore Help
Register Sign In
scossu
/
lakesuperior_legacy
1
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Branch: master
Branches Tags
lakesuperior...
/
docs
/
architecture.rst

architecture.rst 2.4 KB
Permalink History Raw

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758 
  1. Lakesuperior Architecture
    2. 

  2. =========================
    3. 

  3. 

  4. Lakesuperior is written in Python and `Cython
    5. 

  5. <http://cython.readthedocs.io/>`__; the latter for lower-level components that
    6. 

  6. interface with C basic data structures for maximum efficiency.
    7. 

  7. 

  8. Aside from an optional dependency on a message queue server, Lakesuperior aims
    9. 

  9. at being self-contained. All persistence is done on an embedded database. This
    10. 

  10. allows a minimum memory and CPU footprint, and a high degree of scalability,
    11. 

  11. from :doc:`single-board computers <rpi>` to multi-core, high-load servers.
    12. 

  12. 

  13. Inefficient applications "get the job done" by burning through CPU cycles,
    14. 

  14. memory, storage and electricity, and spew out great amounts of carbon and
    15. 

  15. digits on cloud provider bills. Lakesuperior strives to be mindful of that.
    16. 

  16. 

  17. Multi-Modal Access
    18. 

  18. ------------------
    19. 

  19. 

  20. Lakesuperior services and data are accessible in multiple ways:
    21. 

  21. 

  22. -  Via HTTP. This is the canonical way to interact with LDP resources
    23. 

  23.    and conforms quite closely to the Fedora specs (currently v4).
    24. 

  24. -  Via command line. This method includes long-running admin tasks which
    25. 

  25.    are not available via HTTP.
    26. 

  26. -  Via a Python API. This method allows to use Python scripts to access
    27. 

  27.    the same methods available to the two methods above in a programmatic
    28. 

  28.    way. It is possible to write Python plugins or even to embed
    29. 

  29.    Lakesuperior in a Python application, even without running a web
    30. 

  30.    server. Also, only this way it is possible to access some of the lower-level
    31. 

  31.    application layers that allow to skirt much heavy-handed data processing.
    32. 

  32. 

  33. Architecture Overview
    34. 

  34. ---------------------
    35. 

  35. 

  36. .. figure:: assets/lakesuperior_arch.png
    37. 

  37.    :alt: Lakesuperior Architecture
    38. 

  38. 

  39.    Lakesuperior Architecture
    40. 

  40. 

  41. The Lakesuperior REST API provides access to the underlying Python API.
    42. 

  42. All REST and CLI operations can be replicated by a Python program
    43. 

  43. accessing this API.
    44. 

  44. 

  45. The main advantage of the Python API is that it makes it very easy to
    46. 

  46. maipulate graph and binary data without the need to serialize or
    47. 

  47. deserialize native data structures. This matters when handling large ETL
    48. 

  48. jobs for example.
    49. 

  49. 

  50. The Python API is divided in three main areas:
    51. 

  51. 

  52. -  Resource API: this API in charge of all the resource CRUD operations and
    53. 

  53.    implements the majority of the Fedora specs.
    54. 

  54. -  Admin API: exposes utility methods, mostly long-running maintenance jobs.
    55. 

  55. -  Query API: provides several facilities for querying repository data.
    56. 

  56. 

  57. 

  58. See :doc:`API documentation<api>` for more details.
    59.